Windows
macOS
Android
iOS
跨地域业务通常同时运行在北京、新加坡、法兰克福等位置。用户距离、链路质量、节点容量和数据一致性都可能不同，因此节点负载均衡策略不能只看“哪台服务器空闲”，还要判断请求应到哪里、节点是否真正可用，以及切换后业务能否继续完成。
下面列出五种常见做法。它们可以单独使用，也可以组合成多层架构；选择时应先明确业务是静态内容、无状态接口，还是依赖会话与区域数据的交易系统。
一、基于 DNS 的地域或权重调度
DNS 调度是部署门槛较低的节点负载均衡策略。权威 DNS 根据用户来源、运营商、记录权重或健康状态返回不同节点地址。Amazon Route 53、Cloudflare Load Balancing 等服务都提供类似的流量管理能力，但具体规则和计费方式需要以实际产品文档为准。
适用条件与限制
- 适合静态资源、公开 API 和能够容忍短时间切换延迟的业务。
- 权重调度便于灰度发布，例如先让约 10% 的请求进入新区域，再逐步增加比例；实际比例会受缓存、解析器行为和客户端重试影响。
- DNS 结果会被递归解析器和终端缓存，TTL 较长时，故障切换可能不能立即生效；TTL 较短又会增加解析请求量。
实施时先为每个区域建立独立入口，再配置地域、权重和备用记录，最后从多个网络位置验证解析结果。健康检查应检查业务入口而不只是主机存活，例如读取公开的版本接口，并为连续失败设置观察窗口，避免短暂抖动造成频繁切换。
二、使用 Anycast 把用户引到就近接入点
Anycast 让多个地点使用同一组 IP 前缀，由网络路由把用户通常引向拓扑上较近的接入点。Cloudflare、Google Cloud 的全球网络以及部分云厂商的全球负载均衡产品都采用了类似思路。
这种节点负载均衡策略适合图片、视频分发、边缘缓存和无状态 HTTP 服务。它的优势是用户不必等待 DNS 重新解析，入口地址相对稳定；不足是“路由上最近”不一定等于应用延迟最低，某个接入点异常时也需要依靠网络撤销路由、边缘健康检查或上层流量策略完成收敛。
- 为各区域准备一致的服务入口和证书配置。
- 在边缘层配置缓存、限速和异常节点摘除规则。
- 分别从北京、东京、法兰克福等测试位置观察首字节时间、错误率和回源延迟。
- 确认区域节点被撤出后，请求能够转到仍有容量的地点。
三、采用全局流量管理器进行智能选路
全局流量管理器，也常被称为 GSLB，可综合地域、往返延迟、节点健康、连接数或自定义权重做决定。与单纯 DNS 地域映射相比，它通常能同时纳入更多运行指标，适合跨地域 API、SaaS 控制台和多活服务。
| 调度依据 | 优势 | 注意事项 |
|---|---|---|
| 地域 | 规则清晰，便于区域合规和就近访问 | 用户出口位置与真实使用位置可能不同 |
| 延迟 | 更贴近网络体验 | 探测时间、网络时段会影响结果 |
| 权重 | 适合扩容、灰度和容量分配 | 权重不等于精确请求比例 |
| 健康状态 | 能在区域异常时转移流量 | 必须区分应用故障与探测链路故障 |
配置这类节点负载均衡策略时，建议先把“可接收流量”定义清楚：节点不仅要能返回页面，还要能访问必要的缓存、消息队列或数据库。对于写入业务，应先确认跨区域复制延迟和冲突处理方案，再开启自动故障转移。
四、在区域入口部署应用层网关
第四种做法是在每个区域放置应用层网关，由网关按路径、请求头、租户或服务状态转发到本区域和其他区域。它能够识别 HTTP 方法、URL 和响应码，比网络层转发更适合微服务、版本发布和接口拆分。
例如，访问欧洲用户的订单接口时，可优先进入法兰克福区域；静态资源则转到缓存命中率更高的节点。网关还可以设置连接超时、重试次数和熔断阈值。不过，自动重试不应随意用于支付、下单等非幂等请求，否则可能造成重复提交。
落地步骤
- 先按域名或路径划分流量，并标记哪些请求可以安全重试。
- 为每个区域配置独立后端池，设置连接、响应和空闲超时。
- 将只读请求与写入请求分开，写入请求优先进入拥有权威数据的区域。
- 通过压测和故障演练确认网关在单区域不可用时不会形成重试风暴。
五、由客户端或 SDK 进行节点选择
移动应用、桌面软件和边缘设备可以在启动时获取多个服务地址，再依据探测结果、历史延迟和失败次数选择节点。这种节点负载均衡策略不依赖所有流量经过同一个中心入口，适合设备数量可控、能够更新客户端配置的场景。
缺点是控制逻辑分散在客户端版本中，旧版本可能继续使用失效地址；同时，客户端探测与真实业务请求的表现不一定一致。实现时应提供配置下发、地址过期时间和紧急禁用开关，并保留服务端兜底路由。探测可使用轻量健康接口，避免让每台设备频繁执行完整登录或大文件下载。
如何选择合适方案
只需要基础容灾时，可从 DNS 权重或地域调度开始；重视稳定入口和边缘接入时，优先考虑 Anycast；需要按延迟、容量和健康状态综合决策时，选择全局流量管理器。应用层网关适合复杂路由与灰度，客户端选路则适合具备版本控制能力的专用终端。
实际项目常采用组合方案：外层用 DNS 或 Anycast 进入区域，区域内再用应用层网关分配服务。无论采用哪种节点负载均衡策略，都应持续记录解析延迟、连接成功率、接口错误率、切换耗时和数据同步状态，并通过定期演练验证故障转移不是“配置上可用”而是业务上可用。
常见问题
1. DNS 调度能否做到实时切换？
通常不能完全实时。缓存和递归解析器会影响生效时间，TTL 只能影响一部分缓存行为，不能保证所有客户端立即更新。
2. 延迟最低的节点一定是最佳节点吗？
不一定。节点还可能受容量、错误率、数据权限和同步状态限制。延迟应与健康状态和业务可用性一起判断。
3. 多区域是否必须部署多活数据库？
不必须。可以采用主备、分区写入或只读副本，但必须明确故障时哪些数据可读、哪些操作需要回到权威区域。
4. 什么时候不适合自动跨区域重试？
支付、扣款、创建订单等非幂等操作不宜盲目重试，应使用幂等键、状态查询或人工补偿流程降低重复执行风险。
5. 节点负载均衡策略上线前要验证什么？
至少验证正常分流、单节点故障、单区域故障、恢复后的回流、会话连续性和数据一致性，并记录每一步的切换时间与错误变化。