跨区访问变慢，或某个机房断电、网络中断时，切流的关键不只是把请求导向别处：备用地域还要有可用主机、所需数据和完整依赖。设计多地域灾备主机与流量切换方案时，可从四种方式中选择，也可以组合使用。
先明确切换边界：主机能接流量吗
切换前先确认备用地域的计算资源已经启动，应用版本和配置一致，数据库或文件数据能够读取，证书、密钥、队列等依赖也可用。若两地都能处理写入，还要设计数据冲突的处理规则；否则，切流可能让服务恢复，却造成数据不一致。
健康检查应覆盖实际服务能力，而非只判断主机是否通电。可以设置独立的应用探针，检查关键依赖是否可达，并为切换设置人工确认或连续失败条件，减少短时抖动引发的误切。
四种流量切换方式，各有适用范围
1. DNS 故障切换：适合入口简单的站点
通过权威 DNS 将域名解析到正常地域，探测到故障后改为备用地址。优点是架构容易理解、接入门槛较低；限制是递归解析器和客户端可能缓存旧记录，切换不会对所有用户同时生效。对持续连接也不能保证无感迁移。
实施时，为主备地址分别设置健康检查，验证备用服务后再启用自动切换；故障恢复后不要立刻切回，可先观察并分批恢复流量。此方法适合容忍短暂地域差异、入口结构较简单的业务。
2. 全局负载均衡：按健康状态调度请求
全局负载均衡可依据健康检查、地域或权重，把用户请求送往不同区域。相比 DNS 切换，它通常能提供更细的流量控制，适合需要逐步导流或同时使用多个地域的服务。Google Cloud 的全球外部应用负载均衡器是这类产品的一个具体例子；实际能力和配置方式应以所选产品文档为准。
操作上，先把各地域的服务端点加入后端池，配置覆盖关键业务依赖的探测，再以小比例流量验证备用地域，确认错误率和容量正常后逐步提高权重。需要留意负载均衡器本身的配置、权限和依赖，避免它成为新的单点。
3. Anycast 与 BGP：在网络层改变流量路径
Anycast 可让多个地点对外公布同一 IP 地址，由网络路由把用户流量送往可达的入口；BGP 路由撤回或调整可用于把流量从故障地点移开。它适合具备网络工程能力、对入口路径控制要求高的系统。
它处理的是网络可达性，不一定能识别应用是否正常：主机仍在线但服务已失效时，单靠路由状态可能发现不了问题。应把应用健康信号接入路由发布策略，并确认运营商路由收敛时间和备用入口容量，再开展演练。
4. 应用层服务发现：适合服务间调用
应用或服务代理依据实例健康状态，将内部调用转向其他地域。与面向公网用户的入口切换相比，这种方式能按服务粒度调整，适合微服务之间的跨区调用；但需要管理服务注册、客户端缓存和连接重试，配置复杂度较高。
部署时先给每个服务定义可判定的健康状态，再配置调用超时、有限次数的重试和备用地域地址。重试不能无限进行，否则故障期间请求会堆积，进一步拖慢系统。
如何选，以及怎样落地
入口简单、可接受缓存造成的延迟时，可考虑 DNS；需要按区域或权重精细导流，可考虑全局负载均衡；已有网络路由管理能力且关注网络入口切换，可评估 Anycast；内部服务调用需要按服务单独切流，则适合服务发现。实际的多地域灾备主机与流量切换方案常组合使用，例如公网入口用全局负载均衡，内部调用再使用服务发现。
- 列出主地域、备用地域、入口、数据源及外部依赖，标明哪些可自动切换。
- 确认备用主机、应用版本、配置与数据可用，并测算其能承接的并发和请求量。
- 选择切流机制，配置健康检查、告警、权限和回切条件；先在非高峰时段验证。
- 演练单地域故障，记录发现、切换、验证和恢复步骤，修订仍依赖人工判断的环节。
切流方式没有脱离业务的统一答案。能否恢复，取决于备用主机与依赖是否就绪、健康判断是否可靠，以及团队是否验证过完整流程。把这三项纳入设计，比单纯追求更快的切换更重要。
常见问题
一定要让两个地域同时承接流量吗？
不必。主备架构更容易控制写入，但备用资源要定期验证；双活能利用两地资源，也要求处理数据一致性与跨区调用问题。
DNS 切换能做到所有用户立即生效吗？
不能保证。解析缓存和客户端行为会影响生效时间，应在演练中观察实际解析结果和旧连接存续情况。
机房恢复后要立即切回吗？
不建议仅因探测恢复就切回。先确认原地域稳定、数据状态符合预期，再分批恢复流量并观察错误情况。
小型系统应从哪种方式开始？
可先采用结构较简单的入口切换方式，并准备可验证的备用主机和人工操作步骤；随着多地域调用与流量控制需求增加，再评估更精细的方案。
