多地域容灾场景下做全局调度，核心思路是“DNS解析做入口分流、中心化决策引擎做实时调度、Anycast做就近加速”，三者各司其职，才能既容灾又保证访问质量，缺一不可。
为什么本地负载均衡解决不了多地域容灾的问题
传统负载均衡（比如Nginx、LVS）服务的是同一个机房内的多台服务器，它关注的是“这一组机器”怎么把流量分均匀，但多地域容灾场景下，用户可能在上海，机房在杭州和北京，问题变成了“让用户访问哪个区域”，而不是“让请求打给哪台机器”,这是两个层面的调度逻辑。
打个比方：本地负载均衡是你在商场里找收银台，哪个收银台排队短就去哪个；全局调度是在你出门之前就决定去哪个商场，根据距离、拥堵、是否营业实时调整，如果每个商场的收银台都排得很短，但商场本身已经关门了,你的购物计划照样泡汤。
所以多地域容灾的全局调度，首先要解决的是入口选择问题，常见的做法是DNS解析调度，用户输入域名时，DNS服务器返回哪个区域的机房IP，用户就去访问哪个区域，但DNS解析有个缺陷DNS缓存，公共DNS服务商会把解析结果缓存一段时间（TTL），就算你紧急切换机房，用户也可能在5到10分钟内继续访问故障机房，行业共识认为，纯DNS调度的可用性上限受限于缓存刷新率,关键业务不能只靠它兜底。
全局调度的决策引擎怎么设计
真正靠谱的全局调度，底层一定有一个实时感知全链路状态的决策引擎，这个引擎的功能是：不断收集每个地域机房的健康状态、负载水位、网络延迟、丢包率，然后算出一个“最优分发比例”,再通过DNS或者HTTP重定向的方式下发。
设计这个决策引擎时,主要分三步。
第一步：健康检查要分层
健康检查不能只检查机器端口通不通，那太粗糙了，一个机房可能所有服务器都活着，但整个机房的出口带宽被人打满了，此时用户访问体验已经崩溃,所以要三层检查：
- 第一层是硬件和进程层：检查CPU、内存、核心进程存活，这层挂了,直接摘除。
- 第二层是业务逻辑层：模拟真实请求访问核心接口，确认返回结果正确，不只是返回200状态码,返回200但响应体报错的情况太常见了。
- 第三层是链路质量层：从多个探测点（覆盖运营商、覆盖主要地域）主动发起访问，测TCP连接耗时、首字节耗时、丢包率，这层数据最有参考价值,因为用户体验就是这几毫秒和几个百分点的波动累计出来的。
三层检查频率建议分开，进程层可以5秒一次，业务层15秒一次，链路层30秒一次，频率太高会消耗业务资源,太低则发现故障太慢。
第二步：权重计算不要只盯着CPU
很多自研调度脚本的鸡肋之处在于：只把服务器CPU和内存使用率拿来算权重，然后加权分发，这在单地域没问题，但全局场景下，网络距离的权重应该高于机器负载。
比如
北京的机房CPU使用率30%，广州的机房CPU使用率50%，但用户在上海，上海到北京的网络延迟是15毫秒，到广州是30毫秒，此时宁可让用户多花一点等待时间去访问北京，也不应该放到广州，因为多出来的网络延迟远比那20%的CPU率更影响体验。
一个合理的全局权重计算公式,至少包含三个因子：
- 地域距离因子：用户来源归属地到各机房的网络延迟（通过IP库归属判断）
- 容量因子：当前机房的剩余可用容量（注意是剩余容量，不是已用容量，一台已用80%的机器比一台已用60%的机器风险高得多）
- 稳定性因子：近5分钟内该机房健康检查的成功率，如果低于95%，权重直接减半
调度策略引擎建议用独立的服务部署，不要跟业务应用部署在一起，它可以跑在单独的容器里，通过API拉取各机房的监控数据，一旦监控系统故障，调度决策不了，此时应启动应急策略默认全部流量按备份权重分发,而不是干等。
第三步：下发方式决定切换速度
决策引擎算出权重，怎么让全局节点知道？目前主流有三种下发方式,差异化明显。
第一种是标准DNS解析，修改权威DNS上各记录值对应的权重参数，这种方式胜在简单，但受限于客户端的LocalDNS缓存和递归解析器的TTL限制，在极端情况下切换耗时可能长达数分钟，统计显示，TTL设置5分钟时,实际生效时间平均在8到10分钟。
第二种是HTTP重定向（302跳转），比如访问统一入口域名，应用层网关收到请求后，根据用户所属的IP段，直接302到对应的区域业务域名，这个方式不需要依赖DNS，因为用户请求已经到达了你的网关层，优点是秒级生效，缺点是所有流量都会先经过一次网关,网关本身的区域容灾就变成了新的课题。
第三种是Anycast，就是多个地域的机房宣告同一个IP地址段，让互联网路由器通过BGP协议选路，把用户请求送去最近的那个机房，这个方式在容灾切换时效果极佳某个机房抖动时，路由器自动收敛，无需执行任何切换操作，但部署门槛较高，需要有自己的IP段和AS号，一般中小企业难以自建,通常使用云厂商提供的Anycast服务。
容灾切换时怎么收拢流量
刚才说的是日常调度，如果是某一地域机房发生局部故障，怎么快速收拢流量？如果调度完全依赖DNS权重调低，面临的主要矛盾是存量连接做不到及时掐断，用户已经建立的长连接,不会因为你改了一个DNS记录就自动断开。
行业内相对成熟的方案是：DNS摘除域名 + 网关主动断连 + 连接地址失效三者结合。
具体操作路径是，在发现故障的第一时间，先在集中式配置中心将故障机房的全部入口域名权重置0，同时在智能DNS上将该机房的解析结果全部替换为备用机房IP，对于已经在途的用户请求，通过在故障机房的接入层网关执行Reset接入连接（而不是等待原有超时机制），强制让客户端发生断线重连，重连时客户端会重新发起DNS解析，此时拿到的是备用机房地址,流量自然切换。
这一步必须依赖自动化工具完成，不建议人为登录服务器去改配置，人为操作的平均响应时间在三到五分钟，自动化脚本可以控制在10秒内，实现自动化时，特别要注意设置依赖方向安全开关：当全局调度系统探测到某个机房连续3次检查失败时，在切换之前必须确认该机房没有承担全站某个核心依赖（例如唯一的注册中心、唯一的数据库写入点）,否则全站业务可能直接雪崩。
全局负载均衡的真实场景融合
在设计多地域容灾架构时，有一种常见误区是：把全局负载均衡当成一个地方卖的硬件设备或者一个独立软件，安装完成就生效了，全局调度能不能做好,和你的整体业务架构强相关。
常见的两种部署形态如下：
同城双活机房，两机房物理距离在几十公里内，使用专线互联，延迟大约在1到3毫秒，此时A机房和B机房都承载读写流量，全局调度策略是：本地优先，同城冗余，用户在A城市的流量默认进A机房，A机房故障，自动全部送到B机房，此处对全局调度要求较高的是“不能乒乓切换”，如果A机房轻微抖动就被摘除，没过几分钟恢复了又被添加回来，数据库同步延迟可能导致两边数据不一致，业务出现读写冲突，所以调度系统必须设置冷却时间：某个机房被摘除后，至少稳定运行15分钟以上才允许重新恢复流量，而且恢复时权重从10%逐步加到100%。
异地灾备机房，C机房在几千公里外，专线延迟较高，这种场景下全局调度的主要目标是“保数据不丢，保服务可用”，而非保证异地访问体验和本地一样流畅，此时DNS权重调度发挥作用：正常情况下C机房权重几乎为0%，仅承载异步数据同步流量；只有当A和B两个城市机房同时不可用时，才将100%流量切换至该地，这种情况下，日常就要保持C机房的业务包版本、数据库结构、配置管理完全和主用一致，否则真正切换时你面对的不只是流量切不动,更是起不来应用。
行业专家指出，多数灾备切换失败的案例，不是起因于调度系统没把流量引到灾备机房，而是灾备机房本身没有做好常态化的排障和演练，全局调度解决的是“到哪儿去”的问题，但“到了之后能不能活”还得靠备份环境的持续可用。
做好全局调度还依赖可观测体系
说完调度逻辑本身，别忘了配套的可观测体系，如果没有一套覆盖全局的拨测机制来验证用户体验质量，你根本不知道调度的效果是好是坏，这里有一个实操建议：在重点城市部署4到8个拨测点，覆盖电信、联通、移动三大运营商网络，每30秒发起一次全链路探测，拨测维度包括DNS解析时间、建连时间、TLS握手时间、首包时间、内容加载完整率，拨测结果实时汇总成波形图，一旦某一城市对某一机房的综合耗时超过告警阈值,自动触发调度策略重新计算。
全局调度系统需要记录每一次调度决策的上下文，包括“什么时间、因为什么原因、将多少流量从A切到了B”，这类历史数据在复盘容灾演练时价值非常大，你会发现，很多故障其实早就有苗头只是监控数据没有被调度系统纳入决策因子。
最后要明确一个现实：全局负载均衡不是一台设备、一串命令或者一套软件能解决的全部，它是一个持续运行、不断反馈、逐步迭代的决策循环，刚开始可能只能做到“故障切换”，随着拨测数据和调度日志的积累，会逐步进化到“预防性调度”，最终做到“质量优先调度”，这个演进过程要求调度系统打通DNS、负载均衡、监控告警、配置中心四个系统之间的数据流通。
不要小看这一步，据统计，多地域容灾场景下真正有效的全局调度方案，来自运维团队与网络团队的对齐情况，远比技术选型更重要没有统一的故障切换SLO定义,调度系统做得再精致也找不到发力方向。
Q&A
全局负载均衡和本地负载均衡有什么区别？
本地负载均衡关注的是同一地域机房内部的服务器流量分配，它解决的是“每一台机器的压力是否均衡”的问题，全局负载均衡关注的是用户应该访问哪个地域的入口资源，它解决的是“哪个地域、哪一组集群更有能力服务于这位用户”的问题，前者是后者的子集，全局负载均衡的决策结果通常由作为入口的本地负载均衡集群，或者DNS解析服务来完成流量接入，全局调度更强调线路质量、容灾能力和实时决策能力，而本地分配更看重会话保持、健康检查和单机房内的高可用保障。
全局负载均衡哪家方案更靠谱？
这个问题取决于你的部署环境和能力边界，如果是纯自建机房，各云厂商都提供GSLB商业化产品，本质上都是DNS调度加HTTP重定向的组合，差异化不大，选型重点在于API开放性以及跟现有监控系统的打通能力，如果业务已上云，建议使用云厂商自带的全局流量管理服务，并与云上的健康检查和拨测打通，如果希望完全掌控故障切换逻辑，可以用BGP Anycast或者自研DNS权重调度系统前者成本较高，适合对容灾等级要求极高的核心业务，后者则适合有一定开发能力的团队，没有绝对靠谱的方案，但一个必须避免的方案是：没有自动化、依赖人肉修改解析记录的全局调度，无论用哪种产品，提前规划好切换演练,比纠结选型本身更重要。
跨地域容灾系统如何提前发现故障并自动切换？
提前发现的依据是健康检查数据，自动切换的依据是权重参数变更，每一套核心业务在部署时都应配置多级健康检查模块，分别从TCP端口、HTTP状态、业务逻辑代码三个方向进行探活，当连续健康检查失败次数超过阈值时，调度系统自动将该地域权重的分发比例降为0%，同时对故障地域发起一次确认探测（间隔30秒连续3次），确保不是探针自身的误报，确认故障后执行切换动作，将配置中心中对应地域的接入网关全部摘除，同时放开备份地域的权重上限，整个过程建议控制在30秒内完成，所有动作自动记录到系统日志，多余的动作不做判断哪一步需要人工介入,是调度成熟度的分水岭。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/635445.html
