GSLB 详解：全局负载均衡如何工作，以及 DNS 调度为何在真实流量下失灵

全局负载均衡（GSLB，Global Server Load Balancing）是一种把用户流量分发到多个数据中心或地理区域服务器的技术，通常通过为每个 DNS 查询返回最优可用站点的 IP 地址来实现。它依据服务器的健康状况、负载和地理邻近度，把每个用户路由到最优位置，从而改善访问延迟、可用性与容灾能力。

然而，大多数 GSLB 实现做出路由决策的方式，仍停留在十年前：依赖网络层探测——ICMP ping 与 TCP 握手——只能告诉你节点是否可达，却无法判断它能否扛住当前负载。本文将讲清 GSLB 如何工作、只看连通性的调度为何在真实流量下失灵，以及把调度决策拉回应用层——基于机器负载、请求速率等业务指标，在不同机器乃至不同集群间重新分配流量——如何闭合这个反馈回路。

这就引出了一个经典的运维场景： 监控面板上，某个边缘节点的 CPU 负载出现异常爬升，斜率远超预期。按照标准预案，你登录 DNS 控制台，将该节点的解析权重从 80 下调至 60。由于 TTL 的存在，十几分钟后，流量曲线才开始缓慢回落，但这种滞后的“刹车”导致了另一个节点因承接过多溢出流量而告警。你不得不进行二次修正——但每一次修正，都意味着又要在这个长反馈链条中，再煎熬十几分钟。

在这样反复的微调和等待中，系统总算暂时稳定。但整个过程不仅需要时刻关注监控，还要忍受 DNS 传播的延迟，在焦虑中等待每一次调整生效。流量切换了，服务也扛住了，但这种依赖手动、反复试探换来的稳定，过程繁琐且风险不低，总让人感觉像是在走钢丝。问题解决了，但解决问题的方式似乎并不理想。

传统 GSLB 工具为何力不从心：离散、二值、突变

我们习惯将这类问题归结为“经验不足”或“预案不完善”。但作为工程师，我们更应该审视工具本身：现有的调度工具，是否真正适合处理这类连续变化的场景？

想一下我们最常用的几种调度工具：DNS 权重、健康检查、甚至是一些简单的 GSLB。它们有一些共同的特点：

• 离散：权重值是静态配置，比如 80 或 70。它无法表达“当节点负载达到 75% 时，权重从 80 平滑降低到 75”这类动态、连续的响应策略。
• 二值：健康检查的结果通常只有“通过”或“失败”两种。一个节点要么在线，要么离线，我们无法得知其“亚健康”状态，比如“节点在线，但响应延迟已经开始飙升”。
• 突变：无论是健康检查失败，还是手动将权重降为 0，流量的切换都是断崖式的。这种突变本身，就可能对用户体验和其他节点造成冲击。

这些工具在设计之初，其核心假设是：服务器的状态是相对稳定的，变化是低频的。但在今天，业务的弹性伸缩、流量的瞬时脉冲、服务的优雅降级，都让系统状态变成了一个连续变化的过程。我们试图用“开关式”的离散工具，去管理一个状态连续变化的系统。这种工具与场景的错配，正是运维过程中“不踏实感”的根源。

理想的全局负载均衡系统需要什么

一个更理想的全局流量调度工具，无非是下面三点朴素但关键的期望：

1. 平滑迁移：当某个节点的负载升高并呈现“亚健康”状态时，系统应能自动、渐进地减少其流量，而不是等待人工干预，或节点彻底不可用后才“一刀切”。
2. 自动熔断：当节点负载超过安全阈值，确实无法处理更多请求时，系统应能自动、快速地将其隔离，停止分发新流量，以保护节点自身和整体服务的稳定性。
3. 可观测、可追溯：所有调度决策，无论是自动还是手动，都必须有清晰的记录。我需要能事后审计，在任何时间点，系统到底做了什么，以及决策的依据是什么。

这三点并非高深的技术指标，而更接近工程师对生产工具的本质要求：将重复、高风险的判断自动化，同时将最终的控制权和知情权交还给工程师。

基于反馈的 GSLB 架构：OpenResty Edge 如何调度流量

OpenResty Edge 的 GSLB 功能，正是围绕上述场景设计的。它尝试用一种更贴近真实负载变化的方式来调度流量：基于机器负载、请求速率等自定义业务指标，动态地将流量重新分配到不同的机器，乃至不同的集群。不再单纯看“路通不通”，而是看“业务撑不撑得住”——并据此主动调整流量的去向。

GSLB 健康检查：不只看连通性，更看承载能力

传统的 GSLB 健康检查多依赖 Ping 或端口探测，这只能判断节点“是否存活”，但无法评估其“服务质量”。在 OpenResty Edge 中，这一“存活与否”的基础层由网关服务器健康检查承担：故障节点会被自动从 DNS 解析中移除。

OpenResty Edge 将健康检查的维度从网络层推进到了应用层，许用户根据自身业务特点，自定义用于调度决策的业务指标。以下是几个典型示例：

• requests per second：应用每秒处理的请求数。
• active connections：当前的活跃连接数。
• 系统分钟级的平均负载。

这些自定义业务指标的意义在于，它们不再只关心节点“死活”，而是关心其“服务能力”和“健康度”。当调度系统能够基于真实业务负载做出判断时，就可以将流量动态地重新分配到负载更低的机器，乃至切换到整个备用集群——而不是等到节点彻底不可用才被动响应。我们并非否定传统方案，而是在当前复杂的业务场景下，仅有网络层信息确实不够用了。

水位线模型：渐进降载，而非生硬切换

为了应对“亚健康”状态，OpenResty Edge GSLB 引入了“高低水线（Watermark）”模型，以替代传统的单一阈值。

• 低水位：当节点的某个指标（如 CPU 负载）超过低水位时，系统不会立即移除该节点，而是开始按比例调低其流量权重。这提供了一个缓冲区域，通过平滑、渐进地减少流量，给节点一个“喘息”和自我恢复的机会。
• 高水位：当指标继续恶化并触及高水位时，系统将触发熔断。此时，GSLB 会停止向该节点分发任何新流量，并将其承载的流量自动迁移至同集群内的其他健康节点，乃至跨集群调度至异地备用集群——确保节点不会被彻底压垮，整体服务持续可用。

这种设计的核心是避免流量在节点间剧烈、突兀地切换，它模拟了一个经验丰富的工程师的决策过程：先温和降级，再果断熔断。

可解释性是信任的前提，而非界面点缀

在控制系统中，自动化程度越高，对“状态透明度”的要求就越严苛。对于 GSLB 这种处于流量入口的决策系统，如果运维人员无法在通过日志或面板反推其决策依据，那么这种自动化本质上是不可控的风险。

OpenResty Edge 的 GSLB 提供了直观的可视化面板，清晰地回答了“为什么调度”的问题：

• 计划对比：系统直观展示了 原始 DNS 计划 和经过 GSLB 智能调整后的 GSLB 计划 的差异。
• 流量变化方向：我们通过可视化的权重变化指示，量化了流量迁移的方向与幅度。通过醒目的红绿箭头，你能一眼看出系统正在减少哪些节点的流量，又在增加哪些节点的流量。（绿色表示上升，红色表示下降）
• 历史回放：系统支持回溯任意历史时刻的调度快照。能够精准还原事故发生时的全局流量分布与调度器决策。

可观测性不是自动化的附加功能，而是其前置条件。只有当决策过程可被审计、可被解释时，自动化调度才能真正被纳入生产环境的信任链条中。

GSLB 改造前后：从人工告警到确定性的流量治理

当 GSLB 具备了应用层感知、平滑调度和决策透明的能力后，运维的工作模式也随之改变。

工程师的角色从被动响应的“执行者”，转变为主动规划的“策略制定者”。核心工作变成：

• 定义业务的“健康”模型（选择合适的应用层指标）。
• 定义系统的干预策略（设置合理的水位线和熔断条件）。

将调度逻辑固化为代码，交由控制平面在毫秒级的时间窗内完成“探测-决策-执行”的闭环。相比于人工介入产生的决策延迟与误操作风险，系统化的自动化调度能提供工程所需的确定性。这本质上是将运维团队从重复的熵增对抗中解放出来，使其关注点从通过 SSH 临时修补，转向对系统架构的长期治理。

若您的架构面临以下复杂度挑战，这种应用层视角的 GSLB 将体现出其设计价值：

• 多地域/多集群部署：这是 GSLB 的主战场，能最大化资源利用率和灾备能力。
• 业务峰值不可预测：经常有突发流量，需要系统具备快速、自动的弹性调度能力。
• 非线性流量突发：面对脉冲式流量，常规手段的反馈链路往往过长。您需要的是一套能在边缘侧即时感知并自动执行降级或削峰策略的控制系统，而非依赖告警触发的人工流程。

总结：技术结论

最后，我们对 OpenResty Edge GSLB 的定位做一个技术上的收束。它不应该被视为一个试图接管决策权的“大脑”，而更像是一个运行在边缘侧、具备应用层视野的运行时。它在你划定的策略安全域内，通过更短的反馈弧长，以一种更线性的方式处理流量波动，避免了传统调度“非黑即白”式的生硬切换。

OpenResty Edge GSLB 的核心价值不在于让调度变得“全自动”，而是让系统在负载变化时，其反应不再粗糙和滞后。毕竟流量治理的“颗粒度”，往往决定了系统稳定性的天花板。

如果您的业务正在经历跨地域、高并发的流量挑战，且苦于现有调度策略过于生硬或缺乏弹性，您可以先和我们的架构师聊聊。申请试用，我们的专家团队将基于您的实际业务场景，为您拆解如何通过 OpenResty Edge 实现更平滑的流量调度。

如果您希望进一步探究上述调度逻辑在 OpenResty Edge 中的具体实现，或需要验证其配置的灵活性，可以参考如何使用 OpenResty Edge 中的全局服务器负载均衡（GSLB）功能一文。该文档提供了从基础接入到复杂场景覆盖的完整操作视图。

关于 GSLB 的常见问题

GSLB 是如何工作的？

GSLB 工作在 DNS 层：当用户设备发起 DNS 查询时，GSLB 系统会返回最优可用站点的 IP 地址，这个选择依据服务器健康状况、负载和地理邻近度等规则。具备应用层感知的 GSLB 更进一步，会基于机器负载、请求速率等业务指标，持续在不同机器乃至不同集群之间重新分配流量。

为什么网络层的 GSLB 健康检查不够用？

Ping 和端口探测只能判断节点是否存活，无法反映它的服务质量。一个节点可能在线，但响应延迟已经飙升。应用层指标——每秒请求数、活跃连接数、系统平均负载——能反映真实的运行压力，让调度系统在节点彻底失效之前，就把流量从劣化的节点上迁走。

GSLB 中的水位线模型是什么？

水位线模型用两个阈值取代单一的故障切换阈值。当 CPU 负载等指标越过低水位时，系统会渐进、按比例地调低该节点的流量权重，给它自我恢复的空间。若指标继续恶化并越过高水位，系统触发熔断，并将流量迁移到同集群内的健康节点或异地备用集群。

GSLB 如何支撑容灾？

由于 GSLB 能跨集群调度流量，当某个节点或站点无法安全提供服务时，它可以把负载切换到异地的备用集群。结合多地域、多集群部署，这能在故障期间保持整体服务可用——而且每一次调度决策都有记录，事故之后可以回溯审计。

关于 OpenResty Edge

OpenResty Edge 是一款专为微服务和分布式流量架构设计的全能型网关软件，由我们自主研发。它集流量管理、私有 CDN 构建、API 网关、安全防护等功能于一体，帮助您轻松构建、管理和保护现代应用程序。OpenResty Edge 拥有业界领先的性能和可扩展性，能够满足高并发、高负载场景下的苛刻需求。它支持调度 K8s 等容器应用流量，并可管理海量域名，轻松满足大型网站和复杂应用的需求。

关于作者

章亦春是开源 OpenResty^® 项目创始人兼 OpenResty Inc. 公司 CEO 和创始人。

章亦春（Github ID: agentzh），生于中国江苏，现定居美国湾区。他是中国早期开源技术和文化的倡导者和领军人物，曾供职于多家国际知名的高科技企业，如 Cloudflare、雅虎、阿里巴巴, 是 “边缘计算“、”动态追踪 “和 “机器编程 “的先驱，拥有超过 22 年的编程及 16 年的开源经验。作为拥有超过 4000 万全球域名用户的开源项目的领导者。他基于其 OpenResty^® 开源项目打造的高科技企业 OpenResty Inc. 位于美国硅谷中心。其主打的两个产品 OpenResty XRay（利用动态追踪技术的非侵入式的故障剖析和排除工具）和 OpenResty Edge（最适合微服务和分布式流量的全能型网关软件），广受全球众多上市及大型企业青睐。在 OpenResty 以外，章亦春为多个开源项目贡献了累计超过百万行代码，其中包括，Linux 内核、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl 等，并编写过 60 多个开源软件库。

关注我们

如果您喜欢本文，欢迎关注我们 OpenResty Inc. 公司的博客网站 。也欢迎扫码关注我们的微信公众号：

翻译

我们提供了英文版原文和中译版（本文）。我们也欢迎读者提供其他语言的翻译版本，只要是全文翻译不带省略，我们都将会考虑采用，非常感谢！