千万级QPS架构演进：从手动配权到自动化跨域流量调度实战

当系统规模还处于百万 QPS 级别时，跨域流量调度往往还停留在依靠地域进行静态分配的阶段：运维团队依据各地域的用户分布和机房容量，手动配置 DNS 或 GSLB 的权重，遇到故障时再介入进行人工切换。这种方式在流量规模可控、机房数量有限的场景下是可行的。

然而，一旦系统规模演进到千万 QPS，情况就发生了质变。机房数量从个位数扩展到十几个甚至几十个，流量波动变得极其剧烈且难以预测，任何一次人工决策的延迟都可能导致大面积的服务降级。因此，跨域流量调度必须完成从人工决策到系统自决策、从静态配置到实时反馈的根本性转变。

这并非否定百万 QPS 系统自动化的可能性，而是强调在千万 QPS 的规模下，自动化调度已经不再是一个锦上添花的功能，而是系统能够稳定运行的基本前提。

01 百万 QPS 阶段：以人为中心的静态调度

1.1 典型架构

在这个阶段，跨域调度的核心通常是 GSLB（Global Server Load Balancing），配合 DNS 解析来实现基于地理位置的流量分配。GSLB 通过 DNS 的方式，将不同地域的用户引导到距离最近或负载相对较低的机房。其决策链条相对简单：

1.2 运作方式

这个阶段的调度体系有几个典型特征：

• 决策依据单一。主要基于用户 IP 的地理归属进行就近分配，辅以人工设定的权重比例。例如，华东用户默认路由到上海机房，华南用户则路由到广州机房。
• 调整频率低。权重和策略的变更通常以天或周为单位，由运维团队根据容量规划手动调整。遇到大促等特殊场景，则会提前制定预案，按计划执行切换。
• 故障切换依赖人工。当某个机房出现问题时，需要运维人员通过监控发现异常，再手动修改 DNS 或 GSLB 配置来迁移流量。从发现问题到完成切换，整个过程通常需要数分钟。
• 容错机制简单。大多依赖于 GSLB 自带的健康检查功能，以 HTTP 或 TCP 探测为主，探测频率和故障判定逻辑都相对粗糙。

1.3 为什么这套方案能工作？

百万 QPS 的系统通常覆盖 2 到 5 个核心机房，流量分布相对稳定，地理就近策略已经能覆盖大部分场景。各机房之间的容量差异不大，即便分配不够精确，单个机房也有足够的冗余容量来消化偏差。同时，故障发生的频率较低，人工介入的成本尚在可接受的范围内。

02 千万 QPS 阶段：以系统为核心的动态调度

2.1 为什么静态调度不再可行？

当系统规模达到千万 QPS，静态调度方案将面临三个核心挑战：

1. 机房规模扩大，组合复杂度爆炸。机房数量从几个增长到十几个甚至更多，覆盖多个地域和运营商。调度决策不再是简单的“南北分流”，而是需要在数十个节点之间进行精细化分配。人工决策已难以综合考虑所有节点的实时状态和各种约束条件。
2. 流量波动更加剧烈和不可预测。千万 QPS 级别的系统面向海量用户，突发流量（如热点事件、病毒式传播）的峰值可能在秒级内涌入。如果等到运维人员观察到监控告警再进行调整，流量洪峰可能已经过去，或者已经造成了局部过载。
3. 故障影响面显著放大。在千万 QPS 的体量下，一个机房承载的流量可能就达到百万 QPS 级别。一旦发生故障，需要在极短时间内将这部分流量平滑转移到其他机房，同时还要精确评估接收方的剩余容量是否足够。人工操作的响应速度和判断准确性都难以满足要求。

下表清晰对比了两个阶段在关键调度维度上的差异：

2.2 自动化调度的核心架构

千万 QPS 级别的自动化调度系统，本质上是一个 感知、决策、执行 的闭环控制系统。

• 感知层 负责实时采集多维度的数据：各机房的健康状态、当前承载的流量、服务的响应延迟和错误率、剩余可用容量等。这些数据需要在秒级内汇聚到决策中心。
• 决策层 是整个系统的“大脑”。调度策略引擎需要综合多个维度的输入，结合动态容量模型和业务约束（例如某些业务因数据合规性必须在特定机房处理），计算出最优的流量分配方案。约束条件校验则确保调度结果安全，例如不会将过量流量引向一个已经高负载的机房。
• 执行层 负责将决策结果落地到实际的流量路径上。这通常涉及多个执行通道：更新 GSLB 权重以影响新连接的分配，通过 HTTPDNS 直接向客户端 SDK 下发最新策略，或者通过入口层（如 Nginx、API 网关）的配置热更新来调整已有连接的路由。

2.3 多通道执行：破解 DNS 生效延迟难题

自动化调度面临的一个关键工程挑战是：决策可以在秒级完成，但传统 DNS 体系的生效时间往往是分钟级甚至更长。LocalDNS 通常有较大的缓存时间且不严格遵守 TTL 设置，这意味着即使 GSLB 侧已经更新了权重，部分用户的流量路径在短时间内也不会改变。

因此，千万 QPS 的调度系统必须建立多通道并行执行的机制，不同通道的生效速度和覆盖范围互为补充。

• GSLB 权重更新 是最基础的通道，适用于所有通过标准 DNS 解析接入的用户。但由于 LocalDNS 缓存的存在，生效时间不可控，通常作为全局流量收敛的兜底手段。
• HTTPDNS 策略下发 直接绕过 LocalDNS 缓存，客户端 SDK 通过 HTTP 接口获取最新的解析结果，可以实现秒级的调度生效。这是移动端场景下最有效的快速调度通道，但前提是客户端需要集成对应的 SDK。
• 入口层路由调整 作用于已经建立连接的用户。通过动态更新入口层网关的路由规则，可以将当前机房的部分流量实时转发到其他机房处理。这种方式生效最快，但会引入跨机房的网络延迟，适合作为故障场景下的应急止血手段。

在实际运行中，三个通道协同工作：入口层调整用于立即止血，HTTPDNS 在秒级内覆盖移动端流量，GSLB 权重更新则在分钟级逐步收敛全量流量。

03 调度决策的演进：从单维度到多维度

3.1 单维度决策的局限

百万 QPS 阶段的调度主要依赖“地理就近”原则，其背后有一个隐含假设：距离用户最近的机房就是最优选择。

但这个假设在多种场景下会失效：最近的机房已经过载、最近的机房正在经历网络抖动、或者由于跨运营商访问导致“地理近但网络远”的情况。

3.2 多维度决策模型

千万 QPS 的调度系统需要建立一个综合评分模型，考量多个维度来做出更精准的决策。

• 地理距离 仍然是基础因素，提供了一个初始的分配基线，但不再是唯一决定因素。
• 网络质量 通过主动探测（各机房延迟、丢包）和被动统计（真实用户请求质量）相结合的方式获取。在实际调度中，网络质量的权重往往高于纯粹的地理距离。
• 机房容量水位 动态反映各机房当前的负载状况和剩余处理能力。调度系统必须确保不会将流量切入一个已经高负载的机房。
• 服务健康度 关注业务层面的运行状态，包括接口的错误率、超时率、响应时间分布等。一个机房可能网络和容量都正常，但应用层存在故障，调度系统需要能够识别并规避。
• 业务约束 是指因数据一致性、合规要求等原因，某些业务必须在特定机房或地域处理。调度需要在优化全局流量的同时，满足这些硬性约束。
• 成本因素 在大规模系统中也至关重要。不同机房的带宽成本、跨网流量费用差异显著，在服务质量达标的前提下，系统会倾向于选择成本更优的路径。

3.3 决策的安全边界

多维度自动决策带来了效率的飞跃，但也引入了新的风险：如果决策逻辑存在缺陷，或输入数据异常，可能导致大规模的流量误调度。因此，千万 QPS 的调度系统必须设置严格的安全约束体系。

• 单次调整幅度限制。每次调度变更不允许超过一定比例（例如单机房流量变化不超过10%），防止一次错误决策导致全局性问题。
• 调整速率限制。即使需要大幅度调整，也会拆分为多次小步快跑，每次执行后观察效果再决定是否继续。
• 兜底保护。如果调度系统自身出现异常（如感知层数据中断），系统应能自动回退到最后一次已知正常的配置，而不是基于不完整的数据继续决策。
• 人工覆盖机制。虽然日常运行完全自动化，但系统必须保留人工干预的入口，允许运维人员在必要时手动锁定或指定调度策略。

这些安全机制构成了一个稳健的决策流程：

04 从十万到千万：跨域调度的演进路线

跨域流量调度的能力是随着系统规模的增长而逐步演进的，并非一蹴而就。

1. 十万 QPS 阶段。系统通常部署在单个或少量机房，用户通过 DNS 解析到最近的接入点即可。此阶段基本不涉及复杂的跨域调度，重点在于单机房内的负载均衡和服务治理。
2. 百万 QPS 阶段。系统扩展到多个机房，引入 GSLB 实现基于地理位置的流量分配。调度策略以人工配置为主，故障切换依赖运维团队的响应。这个阶段的核心挑战是建立可靠的多机房架构和基础调度能力。
3. 千万 QPS 阶段。系统覆盖大量地域和机房，调度决策必须全面自动化。需要引入实时感知、多维度决策、多通道执行的完整调度闭环，同时建立坚固的安全约束体系防止调度失控。这个阶段的核心挑战，已经从“如何调度”转变为“如何安全地自动调度”。

05 总结

跨域流量调度的演进，本质上是决策权的转移：从依赖人的经验判断，转向依靠系统的数据驱动决策。

在百万 QPS 阶段，机房数量少、流量模式稳定、故障频率低，人工决策是够用的，甚至在处理某些复杂场景时比简单的自动化更灵活可靠。

但到了千万 QPS 阶段，系统的复杂度已经超越了人工决策的能力边界：节点太多、变化太快、影响面太大。自动化调度系统承担了持续感知、快速决策、安全执行的职责，而人的角色则从直接操作者，转变为规则制定者、监督者和异常情况下的最终兜底者。

这种转变并非单纯的技术炫技，而是系统规模增长所带来的工程必然。