• 主页
  • 架构
  • 编程语言
  • 数据存储
  • 网络
  • VMware
  • 服务器
  • 组网
  • AI
  • 算法系列
  • 设计模式
  • 读书笔记
  • 思考
  • 工具
  • 其它技术

  • 主页
  • 架构
  • 编程语言
  • 数据存储
  • 网络
  • VMware
  • 服务器
  • 组网
  • AI
  • 算法系列
  • 设计模式
  • 读书笔记
  • 思考
  • 工具
  • 其它技术

国际化机房部署常用方案

2025-05-31

这些年做了很多项目,突然发现很多关键点竟然记不清了。其实这类应该多写,比起理论大家更喜欢实战一些的内容。

现在中国企业往往走出去,需要在海外多个地区的机房部署服务,服务于除中国区的所有国家,这种情况下,服务如何部署、数据如何同步呢?

为什么要多机房部署,为了合规,为了更好的体验,美国人访问新加坡机房的速度肯定慢于访问美国机房。

假设,我们现在需要将服务部署到SG和US两个机房。

常用方案

方案一:机房数据隔离 方案二:机房数据同步
实现方式 image-20250531223345909 image-20250531222448660
核心点 1. 因为数据隔离,用户发起请求前,需要知道该请求要打到哪个机房。有不同的设计方案,如根据用户的注册地,所有的请求打到注册地对应的机房;根据用户选择的地区判断
2. 可以不同机房域名不同或者通过CDN根据path进行回源
1. CDN根据IP就近回源
2. 所有数据双向同步
3. 一般同一个域名

我们看看对于不同的场景,两个方案的支持情况:

  1. 用户迁移场景:如用户从新加坡搬到美国了,方案一会导致用户的时延增加,方案二完全无影响
  2. 必须共享数据场景:如要做邀请码功能,邀请码的数据是必须要共享的,因为任何地区的人都可以兑换。方案二只需要在一个机房生成邀请码即可,对于方案一就比较麻烦
  • 要么只部署一个机房,另一个机房跨地区访问
  • 要么一个机房生成数据后,想办法进行同步到另一个机房。这跟方案二已经比较像了。

需要根据具体场景选择不同的方案。像以前做海外电商,那就是方案一,因为电商有很多配套的子系统,库存系统、商品系统、售后系统等,有些还是三方的,完全做成同步代价太大,那就让用户选择地区就好了。

如果完全是自己公司的系统而且对外提供功能一样,我更喜欢方案二的方式,成本主要在于同步,db、redis、tos等,这需要公司有比较完善的基建功能。方案二其实更加简洁,CDN根据IP就近回源即可,方案一要么让用户选择地区、要么得判断用户的注册地。

CDN回源

以前写过CDN请求过程详解。CDN 厂商常见的回源策略有以下几种:

根据 IP 回源

  • 按照地域 IP 段:CDN 节点可以根据用户请求的 IP 地址所属的地域范围,回源到距离该地域较近或特定的机房。例如,对于来自中国北方地区的用户请求,将回源到位于北方的机房,这样可以利用地理位置优势,减少数据传输距离和延迟,提高回源效率。
  • 根据 IP 访问频率:分析 IP 地址的访问频率,如果某个 IP 地址的访问量较大且持续增长,为了减轻特定源站压力,可以将该 IP 的请求回源到其他具有更高处理能力或负载较低的机房。例如,某大型企业内部网络的 IP 频繁访问 CDN 资源,可将其回源到专门为企业用户优化的机房。
  • IP 白名单 / 黑名单回源:设置 IP 白名单或黑名单。对于白名单内的 IP 地址,可以采用特定的回源策略,如回源到高性能机房以提供更好的服务;而对于黑名单中的 IP 地址,可能会限制回源或直接拒绝服务,从而提高系统安全性。

根据请求路径(Path)回源

  • 静态资源路径:对于不同类型的静态资源,如图片、CSS、JavaScript 文件等,可以根据其路径配置不同的回源策略。例如,将所有图片请求回源到专门存储和处理图片的机房,这些机房可能配备了高性能的存储设备和优化的图像处理环境,有助于快速提供图片资源。
  • 动态资源路径:对于动态资源,如 CGI 脚本、ASPX 页面等,由于其生成过程可能涉及数据库查询、复杂计算等操作,可根据路径将请求回源到具备相应处理能力的机房。例如,将特定业务逻辑的动态请求回源到部署了相应应用服务器和数据库的机房。
  • 特定目录路径:如果网站有一些特殊的目录结构,CDN 可以根据目录路径进行回源。例如,将管理后台相关的路径请求回源到与业务生产环境隔离的机房,以增强安全性和稳定性。

基于缓存状态回源

  • 缓存未命中回源:当 CDN 节点接收到用户请求,检查本地缓存中没有对应的资源时,即缓存未命中,此时 CDN 节点会向源站发起回源请求,获取资源并更新本地缓存,以便后续相同请求可以直接从缓存中响应。
  • 缓存过期回源:为缓存中的资源设置一个有效期(TTL,Time-To-Live),当缓存数据超过这个有效期后,CDN 节点会再次回源到源站,获取最新的资源更新本地缓存,确保用户获取到的是最新内容。

负载均衡回源

  • 轮询回源:CDN 有多个源站时,按照顺序依次将回源请求分配到各个源站。例如,有三个源站 A、B、C,第一个回源请求发送到源站 A,第二个到源站 B,第三个到源站 C,之后循环进行。这种策略简单公平,适用于各个源站性能较为均衡的情况。
  • 加权轮询回源:根据源站的性能、处理能力、带宽等因素为每个源站分配不同的权重。性能高的源站权重较大,被分配到回源请求的概率更高。例如,源站 A 权重为 3,源站 B 权重为 2,源站 C 权重为 1,那么在分配回源请求时,源站 A 获得请求的概率相对更大。
  • 最小连接数回源:CDN 跟踪每个源站当前的连接数,将回源请求发送给连接数最少的源站。这样可以使各个源站的负载更加均衡,避免某个源站因连接过多而性能下降。

智能回源

  • 根据网络状况回源:CDN 实时监测到源站与 CDN 节点之间的网络状况,如带宽利用率、延迟、丢包率等。当某条链路网络状况不佳时,自动将回源请求切换到网络状况良好的其他链路或机房。
  • 根据源站健康状态回源:定期对源站进行健康检查,如检查源站服务器的响应时间、是否能够正常提供服务等。如果某个源站出现故障或性能下降,CDN 会自动将回源请求导向其他健康的源站。

扫一扫,分享到微信

微信分享二维码
引用开源包需要慎重
生活小记
© 2025 John Doe
Hexo Theme Yilia by Litten