做全球负载均衡（GSLB）这项工作，十次里有八次不是因为资历深，而是因为线上出了事故。某天跨地域用户突然反馈访问变慢，或者某个机房整段网络不可达，后台告警响成一片，这时候你才会意识到，光有数据中心内的负载均衡还远远不够，你还需要一个能从全局视角做流量调度、健康检查、故障转移的控制面。这个控制面就是全局负载均衡器 GSLB。

这篇文章想把这些年用 GSLB 的经验系统梳理一遍，从原理到策略，再到实际部署和排障。不谈玄乎的概念，只说能落地的方案，适合刚接触分布式架构、多机房组网或云原生应用的研发和运维同学参考。就算目前业务还只有单机房，把这些机制弄明白，对理解 DNS、高可用和数据中心设计也会有很大帮助。

1. GSLB核心原理：全局视角的流量调度

1.1 GSLB到底解决了什么问题

先说一个容易被忽略的事实：普通的本地负载均衡器（SLB，如 Nginx、LVS、HAProxy）管的是“一个集群内部的多台机器”，它解决的是单点容量和单点故障问题。但它看不到更远的地方，更不知道用户身处哪个地域、哪个机房的链路质量更好、哪个数据中心目前已经快扛不住了。

GSLB 则完全不同。它站在全局的视角，把分布在不同地理位置的多个数据中心、多个集群、多云资源池看作一个整体，然后把用户的访问流量引导到“当前最合适的那个站点”。这个“最合适”可以是最短的网络距离，可以是实时负载最低，可以是链路质量最优，也可以是遵循某种合规要求。

用一个生活化的类比来讲：本地负载均衡像是一个商场的导购，他会根据收银台前排队人数，把你引导到人少的柜台；GSLB 则是跨城市的连锁商家总部调度员，他会先看看哪个门店当前排队短、哪个门店货物充足、哪个门店交通方便，再告诉顾客“你去哪家门店最省事”。

所以 GSLB 要解决的真正问题有三个：多站点间的流量分配、跨地域的动态故障转移、以及站点故障时的“止血”。如果这三个问题你当前用人工改 DNS 还能勉强支撑，那说明业务体量还不用上 GSLB；一旦人工切流需要以分钟级甚至小时级响应，GSLB 就是刚需了。

1.2 核心工作机制：DNS是绕不开的起点

市面上绝大多数 GSLB 产品，最核心的流量接入点都是 DNS。这倒不是因为没有别的办法，而是在现有的互联网寻址体系下，DNS 是用户建连之前必然会经过的一环，天然的“分流闸门”。

原理说来并不复杂。普通 DNS 解析是“域名到 IP”的一对一映射，而 GSLB 会把这一步扩展成“域名到一组 IP 的集合”，然后根据实时策略，在 DNS 应答中返回其中某个或某几个 IP。用户拿到哪个 IP，就会去访问哪个数据中心。也就是说，GSLB 是通过控制 DNS 的应答结果，间接控制用户流量的去向。

这里有一个非常关键的细节，就是 DNS 的 TTL（Time To Live）。TTL 决定了 DNS 解析结果在各级缓存中的存活时间。早期 GSLB 实践里，很多人把 TTL 设得很长，比如 600 秒或者 3600 秒，理由是减少 DNS 查询压力，提升解析速度。但这样做的问题很大：一旦某个数据中心故障需要切换流量，已经缓存了旧解析结果的用户最长会在 TTL 到期前后才重新发起 DNS 查询。真实世界里还有大量递归 DNS（LDNS）不严格遵守 TTL，过期了也继续返回旧记录，于是故障切换被进一步放大。

所以但凡需要依赖 GSLB 做快速故障转移的业务，我一般都会建议把权威解析的 TTL 控制在 30 到 60 秒之间。代价是 DNS 查询量会有一定程度上升，但换来的是分钟级甚至秒级的切换能力，这笔账几乎总是划算的。如果你服务的用户规模特别大，且对延迟不那么敏感，可以把 TTL 放宽到 120 秒，但不要更长了。

1.3 健康检查与故障转移的基本闭环

GSLB 如果只会“按地理位置返回最近的 IP”，那它和静态 DNS 没有任何区别，白白占用一个名声。真正让 GSLB 有价值的是它背后那套健康检查和故障转移的闭环逻辑。

健康检查的逻辑简单说就是：GSLB 通过多种探测方式，持续监测每个数据中心的可用性。最基础的是 ICMP Ping，看主机通不通；更合理的是 TCP 端口探测，确认业务端口能连接；再细致一点还有 HTTP/HTTPS 级别的探测，不只检查端口通不通，还会根据响应码或内容判断业务是否真的正常。

这一点非常重要。我见过不少团队只配了 Ping 检测，结果机房出口光缆断了、交换机仍能拿到 IP，Ping 也通，但业务端口已经无法访问。GSLB 判断“站点存活”，实际上用户已经彻底访问不了，故障完全没被感知。合适的做法是分层配置：网络层探测负责看链路和主机状态，应用层探测负责看真实业务状态，两者结合才算是一个可靠的健康判断。

故障转移的闭环则是：当某个站点的健康检查连续失败达到一定阈值后，GSLB 会把这个站点的 IP 从 DNS 应答池中摘除，用户的解析结果不再包含该站点；与此同时，流量会被自动导向剩余正常站点。等故障站点恢复，健康检查重新通过，它的 IP 才会重新被加入应答池。这套流程说起来简单，但“连续失败多少次才判定故障”“恢复后要不要延迟放量”“切换后是否需要通知运维确认”，这些细节直接决定了系统的稳定性，稍后我会在故障排查章节里详细展开。

2. GSLB调度策略：选路算法的取舍

2.1 基础调度策略：不能只会一种轮询

GSLB 的调度策略是它区别于“静态 DNS 轮询”的灵魂，其本质是一套决策引擎，决定每次 DNS 查询应该返回哪个目标站点。

最常见的几种策略先过一遍。轮询（Round Robin）是最朴素的策略，所有站点轮流返回，适合各站点容量相当、无地域差异的场景，但它根本不知道用户在哪里，也不知道站点当前是什么状态，只能说“能用”。

加权轮询（Weighted Round Robin）则在轮询基础上引入权重，比如两个机房容量比例是 3:1，就按 3:1 的频次返回。这种策略适合新老机房交替期，或者多个云厂商资源配比不均衡的场景。

地域就近（Topology/Geo-based）策略则是根据用户来源 IP 归属位置，返回离它最近的站点。这种策略对体验提升最明显，尤其适合全国甚至全球部署的业务。但它的前提是必须有一份准确度足够的 IP 地址库，而 IP 地址库的准确率从来都不是 100%，尤其对于大量使用 NAT、专线或手机网络的用户，会出现明显偏离。

还有一个容易被忽视的是会话保持（Source IP Hash）。对某些必须绑定用户来源的业务，比如证券交易、内部后台系统，如果同一个用户在不同请求中被 DNS 解析到不同机房，可能会导致登录态失效、数据不一致，这种情况下基于用户网段做哈希，保证稳定解析到同一个站点，会远比“优化链路质量”更重要。

2.2 动态调度策略：用实时数据做决策

静态策略的最大问题是“拍脑袋”。站点 A 的服务器配置高就多分流量，站点 B 网络链路好就分多一点，问题是这些状态每天都在变：某条链路的延迟突然升高，某个机房的 CPU 突然飙升，某个云厂商又宣布了限流。静态规则对这些变化一无所知。

所以更合格的 GSLB 会提供动态调度能力。常见的动态调度会给每个候选站点计算一个综合得分，得分由站点当前负载（CPU、内存、连接数）、链路质量（RTT、丢包率、抖动）、甚至带宽成本等因素加权组成，每次解析时选择得分最高的站点返回。

这里有一个需要冷静看待的点：动态调度并非越“动态”越好。调度决策数据本身存在延迟，数据中心负载指标从采集到反映到 DNS 决策，中间通常有几秒甚至十几秒的延迟；而 DNS 的 TTL 缓存又会让用户实际建连时间晚于决策时间。如果策略变化太频繁，可能出现“振荡效应”，即站点 A 和 B 之间来回切换，反而导致用户访问心率和连接稳定性波动。因此实操上我会对动态策略加上“最小变化间隔”的约束，比如每 30 秒才允许一次调度策略调整，避免剧烈摆动。

2.3 策略组合与业务场景匹配

实际部署中很少只用单一策略，更多的是把策略叠起来用。我在生产环境常用的组合方式是：先用地域性规则锁定“首选站点”的范围，比如华东用户优先走华东机房，华南用户优先走华南机房；在首选站点健康检查异常的时候，才按“最近可用站点”规则做第二跳、第三跳的兜底；如果所有站点都不健康，最后再启用一个只包含容灾站点 IP 的兜底解析池。

这套组合思路的本质，是把“理想调度”和“降级调度”分层。理想情况下，我们追求用户体验最优，让用户靠近源站访问；异常情况下，我们追求业务存活，不管链路是否最优，先保证用户能打开页面再说。

组合策略里有一个经常被忽略但特别重要的点，就是某个站点被判定故障摘除后的恢复预热问题。假设华东机房故障恢复，健康检查已经通过，这时如果把华东机房立刻加入解析池并分配大流量，很有可能会瞬间打满刚恢复的业务，触发新一轮故障。GSLB 一般需要配置“恢复曲线的平滑度”，恢复后的节点应该从较低权重开始，逐步增加到预期水平。这个细节对线上稳定性极其关键，我建议每个负责 GSLB 的运维都去确认一下自己系统是否支持这个能力。

3. 架构落地与实战配置要点

3.1 两种主流架构：权威DNS型与流量转发型

理解 GSLB 的架构选型，是部署前必须想清楚的问题。目前主流方案可以分为两大类：权威 DNS 型和流量转发型。

权威 DNS 型是目前绝大多数商业 GSLB 和自建方案采用的方式，它的核心是让 GSLB 系统本身成为你域名的权威 DNS 服务器。用户发起域名解析时，会直接或经递归 DNS 间接查询到 GSLB，GSLB 根据策略返回对应数据中心的 VIP 地址。这种架构的最大优点是部署成本低，改动都在 DNS 层面，不需要在网络链路上串接额外设备，对现有业务侵入小；缺点是所有调度都依赖 DNS TTL，切换时效最快也只能到分钟级。

流量转发型则是把所有流量先经过 GSLB 入口，再由它根据策略转发到后端的各个数据中心。这种架构下的 GSLB 更像一个全局的七层反向代理。它的优点是能做到秒级甚至毫秒级的切换，更精细地感知连接真实状态；缺点是入口本身成了新的瓶颈和单点，而且跨地域回源流量会带来额外成本和延迟，一般只在企业专网或规模可控的内部系统中采用。

以我个人的偏好，面向公众用户的大规模互联网业务，首选权威 DNS 型；对时延极其敏感、流量规模可控的内部服务，流量转发型会更合适。两种架构各有优劣，没有绝对的对错，关键是匹配业务规模和切换时效要求。

3.2 多数据中心场景下的部署与同步

在实际的多数据中心落地中，最让我提醒关注的一点是：GSLB 控制节点本身也要做高可用和异地冗余。

道理很简单，GSLB 是所有流量的指挥中枢，如果指挥中枢挂了，所有数据中心都会“失去向导”，而用户依然在源源不断地发起 DNS 查询。常见做法是在两个或多个数据中心分别部署 GSLB 控制节点，节点的数据通过可靠通道做实时同步，再在 DNS 层面用 NS 记录把同一子域指向多个 GSLB 节点。

这里牵扯到一个容易踩坑的细节：不同 GSLB 控制节点之间的策略数据和健康检查状态必须保持一致，否则可能出现“华东节点认为机房 A 故障，所以返回机房 B；华北节点认为机房 A 正常，还是返回机房 A”这种分裂状态，最后用户访问行为的差异化程度取决于这两种解析结果，体验会很怪。所以，节点间的数据同步协议和冲突解决策略，要在设计阶段就定好，而不是上线后遇到问题再去补。

另外，各机房的业务网段之间需要留好相应的安全策略和路由，确保健康检查的探测包能正确到达目标业务接口。现实中很多故障切换失败的案例，最后排查出的根因不是 GSLB 配置错了，而是机房防火墙策略变更把健康检查的探测源 IP 给过滤掉了，导致 GSLB 一直误判站点故障。

3.3 关键参数与调优：以一组配置示例为核心

下面给出一组我在实际项目中常用的、比较接近生产的配置骨架，以主流的商业 GSLB 产品配置风格为例，参数上做了一定抽象处理，方便你看懂思路。

domain: demo.example.com
ttl: 30

probes:
  - name: app-probe
    type: https
    url: https://www.example.com/healthcheck
    expected_status: 200
    interval: 10s
    timeout: 5s
    fail_threshold: 3
    success_threshold: 2

pools:
  - name: production-sites
    members:
      - site: beijing-dc1
        ip: 1.1.1.1
        weight: 100
        healthcheck: app-probe
      - site: shanghai-dc2
        ip: 2.2.2.2
        weight: 80
        healthcheck: app-probe
      - site: guangzhou-dc3
        ip: 3.3.3.3
        weight: 60
        healthcheck: app-probe

policies:
  - name: global-routing
    rule:
      - condition: user_region == "beijing"
        action: return beijing-dc1
      - condition: site_status("beijing-dc1") == "down"
        action: return nearest_available_site()
      - fallback: return shanghai-dc2

这份配置里要重点关注三个地方。

第一个是健康检查路径。这里我用了一个专门的 /healthcheck 路径，而不是首页路径。原因是首页往往包含大量动态数据或第三方依赖，一次慢查询可能导致探测超时，而业务本身并没有挂掉；专门的健康检查接口则只返回轻量状态，判断准确度更高。

第二个是 fail_threshold: 3 和 success_threshold: 2 这对参数。它们的意思是连续 3 次探测失败才判定故障，连续 2 次成功才判定恢复。为什么不设成一次失败就切换？因为公网网络本身就存在瞬时抖动，一次丢包或超时不能代表站点真实不可用；但如果失败次数设太大，故障被发现的时间又被拉长了。一般来说 3 次比较平衡。

第三个是 TTL 设置为 30 秒。这个值在快速故障切换和 DNS 查询压力之间算是比较均衡的选择。如果你还有自研客户端的域名解析缓存，需要同时处理客户端侧的缓存策略，否则服务端 TTL 再短都无济于事。

4. 应用场景与选型建议

4.1 典型场景拆解：容灾、多云与加速

GSLB 的应用场景非常广泛，我挑三个最有代表性的来说。

第一个是两地三中心容灾。常见架构是生产中心在 A 地，同城灾备在 B 地，异地灾备在 C 地。正常情况下，GSLB 把所有业务流量引导到 A 地，B 地实时同步数据但业务处于 Standby 状态，C 地定期备份。一旦 A 地整体故障，GSLB 通过健康检查发现生产中心不可用，自动把解析切换为 B 地 IP，这个过程中用户几乎无感知。这套模式的关键点在于，B 地的业务系统必须能承接原本在 A 地运行的所有功能，否则切换过去也只是换了个更贵的停机页面。

第二个是多云多活。很多企业现在同时使用多家云厂商，一方面是为了获取不同的资源优势，另一方面也是为了避免 Single Vendor Lock-in。GSLB 可以根据各云的实时负载、成本、地域分布动态调整流量比例。比如日常 70% 流量分配给云服务商 X、30% 给云服务商 Y；某个时间点 Y 在做大规模变更，就把流量临时全部切到 X，变更完成后再灰量切回来。这种模式对业务的弹性和议价能力都有很大帮助。

第三个是跨地域就近加速。典型需求是全国乃至全球范围内的用户访问，GSLB 通过地址库识别用户位置，把广东用户导向华南节点、山东用户导向华北节点、欧洲用户导向欧洲节点。这种模式下，链路延迟会明显下降，下载和页面打开速度都会有感知提升。它最依赖的就是 IP 地址库的准确性，我建议定期更新地市级别的地址库数据，避免因用户 IP 迁移或归属地变化导致调度偏差。

4.2 与本地负载均衡的区别

GSLB 和本地负载均衡（SLB）总是被放在一起讨论，但两者定位完全不同，这里直接了当地梳理清楚。

本地负载均衡工作在一个数据中心或一个集群内部，它面对的是若干台真实服务器，通过四层或七层转发把请求分发到集群内的不同节点。它的决策频率是“每一次请求”，响应速度是毫秒级，核心能力是吞吐量、连接管理和会话保持。

GSLB 工作在多数据中心之上，它面对的是每个数据中心暴露出来的 VIP 或集群入口，通过 DNS 或转发控制用户流量去向。它的决策频率是“每一次 DNS 解析”，响应速度是秒级到分钟级，核心能力是健康检查、策略调度和故障转移。

用一个简单的比喻做区分：SLB 解决的是“同一栋楼里的几个前台窗口怎么分配客户”，GSLB 解决的是“同一座城市里的几家门店分别承担多少客流”。两者不是替代关系，而是分层配合关系。一个完整的全局流量架构，通常是用户先通过 GSLB 选到某个数据中心的入口，再由该数据中心的 SLB 把请求分发给具体实例。

4.3 商业产品与开源方案的选型

GSLB 的市场选择大致分为三类：云厂商提供的全局负载均衡服务（比如各大公有云的 DNS 负载均衡产品）、传统商业硬件或软件厂商的方案、以及基于开源组件自建的方案。

商业云服务和传统厂商方案的优点是功能完整、支持界面化操作、有比较完善的运维支持，尤其适合中小团队，开箱即用。缺点是价格偏高，且策略和产品演进受制于厂商节奏。

自建方案则更受大型技术团队欢迎。常见的开源组合是：用开源 DNS 服务器（如 PowerDNS 的 PipeBackend、基于 Lua 的脚本扩展）接收 DNS 查询，在查询逻辑中实时读取健康检查模块的状态数据，再动态生成应答。健康检查可以用自研脚本，也可以用开源探活组件来实现；策略决策则可以抽成独立的服务，方便后续做公司内部的调度平台。

选择自建之前我会建议团队先自我评估三点：第一，是否有足够的运营能力保障 DNS 服务的稳定性和带宽容量；第二，是否有精力维护复杂的策略引擎和前端界面；第三，故障场景下团队能否在压力爆表时冷静排查问题。如果三个答案都是否定的，那买商业服务其实是更理性的选择。毕竟技术选型不是面子工程，最终目标是不出事故。

5. 常见问题与排查技巧实录

5.1 故障切换延迟为什么这么长

几乎每一个刚引入 GSLB 的团队都会经历一次这样的困惑：机房发生故障，健康检查也显示异常了，但用户端迟迟没有切换流量，页面还是打不开。明明 GSLB 后台看起来已经切换了，为什么用户还在访问故障机房？

这里最大的嫌疑就是 DNS 缓存。TTL 只是建议过期时间，但不同层级的 DNS 缓存服务器对 TTL 的处理差异很大，有的会忽略 TTL 继续缓存旧记录，有的客户端甚至直接在进程级别缓存了解析结果。所以即便权威服务器立刻返回新 IP，老客户端的解析结果可能要几分钟甚至更长才会刷新。

排查这类问题时，我通常会做三件事：第一，查 GSLB 后台当前的解析结果，确认权威侧策略已经切换；第二，拿一台绕过了本地 DNS 缓存的测试机器，用 dig @权威服务器域名 IP 方式强制查询权威数据，确认权威侧返回了什么；第三，在用户侧使用 dig 域名 +trace 或第三方 DNS 查询工具，逐层检查哪个环节还在返回旧记录。确定是哪层缓存出了问题，再针对性优化，这才是最有效的排查路径。

5.2 缓存导致的调度失灵

缓存不仅会拖慢故障切换，还会直接造成调度策略“失灵”。比如你配置了华南用户走华南站点，但实际测试时发现，其他地域的用户也在请求华南节点。查看解析结果发现，某些递归 DNS 服务器会根据自己所在位置或缓存历史返回旧结果。

这里有一个关键机制必须理解：递归 DNS 是代表用户发起 DNS 查询的，权威服务器看到的查询来源 IP 往往是递归 DNS 的地址，而不是最终用户的地址。很多 GSLB 系统对地域识别的精度受此影响，只能识别到“用户用的是哪家递归 DNS”，而不是“用户的真实位置”。如果某些公共 DNS 服务器部署位置和用户实际地域不一致，就会出现明显的调度偏差。

处理方面，一是尽量使用支持 ECS（EDNS Client Subnet）的解析服务，它能携带部分用户 IP 信息，让权威解析更准确地判断用户位置；二是对调度准确性要求极高的业务，可以放弃依赖 DNS 的解析调度，改用 HTTP 重定向、客户端配置等更精细的方式做切流。做技术选型时想清楚这个层面，能省掉很多线上问题的排查时间。

5.3 探活误判引发的大规模抖动

探活误判是 GSLB 场景下另一类高危故障。字面上看，它和第一种故障方向正好相反：站点本身完全正常，但因为某种原因健康检查失败，GSLB 把健康站点误判为故障并将流量切走了，导致用户访问从“本来正常”变成“全部报错”，完全是无中生有的事故。

最常见的误判原因分为三类。一是探活路径依赖了第三方系统，比如健康检查接口内部会同步请求数据库或缓存，一旦这些依赖变慢，健康检查接口也变慢，探测超时，站点被判死。二是防火墙或负载均衡器对高频探活做了限流策略，尤其是探测间隔过快、并发探测过多时，容易被安全策略拦截，造成大面积误判。三是探活使用的源 IP 或目标路径变动，比如机房调整了白名单，但 GSLB 的探活源 IP 不在白名单内，探测包全部被丢弃。

要根治这类问题，原则是让健康检查尽可能“轻”和“专”。健康检查接口最好不要牵扯下游依赖，只返回应用进程自身的存活状态；网络链路的真实质量交给另一套网络层探测去判断，两类结果分开记录、分开配置阈值。同时，探活的频率也不要设得太激进，通常 10 秒一次即可，连续失败 3 次再切换，这会给你留出应对瞬时抖动的缓冲空间。

5.4 快速排查速查表

最后整理一份我经常用的排查速查表，遇到 GSLB 相关的问题时，照着这个顺序走，大部分场景都能定位到问题所在。

症状	可能原因	排查思路
故障站点未切换	DNS TTL 未过期或递归缓存未刷新	强制查询权威 DNS，检查各层级缓存；考虑降低 TTL
调度结果与策略不符	缺少 ECS 支持	检查是否启用 ECS；换支持 ECS 的解析服务
站点健康状态频繁抖动	探活路径依赖下游或安全策略限流	检查健康检查接口依赖；调整探活频率和超时时间
恢复后流量暴涨引发新故障	缺少恢复平滑机制	配置恢复后权重逐步提升
部分用户跨地域访问	IP 地址库不准或递归 DNS 归属偏差	更新地址库；结合 ECS 提高定位精度

这张表基本覆盖了 GSLB 上线之后 80% 以上的日常疑难杂症。更复杂的问题，比如多级策略组合下的异常调度，就需要结合平台日志和策略命中记录来做深入分析，一般需要把每个用户请求的调度决策链路完整回放才能查得清楚。

一些实操建议与经验总结

这些年在多个项目里调过 GSLB，踩过的坑不少，总结几条实在的经验。第一条是永远不要忽略 TTL 的连锁反应，GSLB 调整策略后，一定要预估客户端缓存的影响，不要看着后台配置已经生效就认为线上已经完成切换。第二条是健康检查设计要单独做为专项来做，探活路径、阈值、频率都需要逐项测试，特别是故障演练时要主动验证“误判”场景，这会比验证“正判”场景更能提升系统的抗风险能力。

另外，建议维护一个 GSLB 切换演练的定期机制。很多团队把 GSLB 部署好以后就再也不碰它，直到真实故障到来才发现各种配置早已失效或过期。一次完整的演练应当包括：模拟主站点故障、确认流量切到灾备、灾备承接期间观察业务指标、恢复主站点并确认流量回切。这个过程不仅验证系统，也验证团队的操作手册和协同流程。

最后分享一个小技巧：在设计 GSLB 策略之前，先统计一下现有业务的用户来源分布和各机房容量上限，用数据说话，能显著减少后面调整策略时的返工次数。GSLB 本质上是流量治理的“大脑”，大脑越清楚业务的规则和边界，做出的调度决策就会越稳定。