千万QPS系统健康检查演进：从主动探测到被动观测，应对灰色故障

负载均衡的一个核心职责，是将流量分发到“健康”的后端节点上。但在不同规模的系统中，“健康”的定义与检测方法大相径庭。在十万 QPS 时代，能响应探测请求基本就等同于健康。而到了千万 QPS 级别，一个能响应探测请求却在真实业务负载下频繁超时的“灰色故障”节点，才是架构师们真正头疼的问题。

解决这个矛盾，健康检查的策略和架构必须随之演进。结论先行：健康检查的演进，本质上是从“探测主导”到“观测主导”的范式转变。

01 两种基本范式

在展开规模演进之前，我们先明确两种健康检查的基本定义和核心差异。

• 主动健康检查（Active Health Check）：负载均衡器按固定间隔主动向后端节点发送探测请求（如 TCP 连接、HTTP 请求），根据响应结果判断节点是否存活。其核心特点是不依赖业务流量，能在零流量时发现节点宕机等基础故障。
• 被动健康检查（Passive Health Check）：负载均衡器通过观察真实业务流量的响应情况（错误率、超时率、延迟分布等），推断后端节点的健康状态。其核心特点是零额外探测开销，检测结果直接反映节点在真实业务场景下的表现。

下图清晰地展示了这两种检查方式截然不同的数据流向：

两者间的核心权衡在于：主动检查能主动发现问题，但只能验证节点的探测能力；被动检查能反映真实业务表现，但必须依赖流量的存在。 它们并非简单的优劣关系，而是两个互补的观测视角，在 系统架构 的不同发展阶段扮演着不同角色。

02 灰色故障：推动架构演进的核心驱动力

在讨论三个阶段的具体演进之前，必须理解一个关键概念：灰色故障（Gray Failure）。

传统意义上的故障是二值的：节点要么工作，要么宕机。但在实际生产环境中，大量故障呈现“灰色”状态——节点没有宕机，端口可以连通，甚至主动探测请求都能正常返回，却在真实业务负载下表现异常。例如：某块磁盘 I/O 变慢导致部分请求超时、GC 停顿引发周期性延迟毛刺、网卡微丢包导致 TCP 重传增多等。

灰色故障的核心特征是：对轻量级探测请求不敏感，但对真实业务流量有显著影响。 随着系统规模增大，灰色故障出现的概率和影响范围也随之增大，主动检查的局限性就愈发凸显。

理解了灰色故障，就能明白为何健康检查架构需要从依赖“探测”转向依赖“观测”。

03 规模演进：从十万到千万 QPS

十万 QPS 阶段：主动检查为主

在此规模下，后端节点通常在几十台量级，负载均衡实例也是个位数。主动健康检查是最自然且够用的选择。

核心特征：

• 后端节点少，探测流量开销可忽略。
• 健康状态采用简单的二值模型（健康/不健康）。
• 策略典型：连续 N 次探测失败则摘除，连续 M 次成功则恢复。
• 各负载均衡实例独立判定，无需状态同步。

被动检查在此阶段通常不启用或仅作为可选项。原因很简单：节点少，灰色故障概率低；即便出现，人工运维也能快速定位。架构简单直接，运维成本低。

百万 QPS 阶段：主动 + 被动协同

当系统演进到百万 QPS，后端节点增长至数百台，负载均衡实例扩展到数十台，两个关键变化出现：

1. 变化一：灰色故障变得常见。 数百台节点中，总会有几台因磁盘老化、网络波动、资源争抢等原因处于“亚健康”状态。它们能通过主动探测，却在真实高并发下表现明显差于同伴。灰色故障从“偶发”变为“常态”。
2. 变化二：被动检查的样本量开始充足。 百万 QPS 分布到数百台节点，每节点每秒处理数千请求。这为被动检查提供了足够的统计样本，使其能通过分析错误率和延迟分布，发现主动探测无法捕捉的亚健康状态。

此阶段的典型架构是主动与被动检查协同工作，互为补充。一个重要演进是：健康状态从二值模型扩展为多级模型。除了“健康”和“不健康”，引入了“亚健康”状态，对应策略是降低流量权重而非直接摘除。在数百台节点的规模下，直接摘除一个仍能承担部分流量的节点，可能导致其余节点压力陡增，引发连锁故障。多级模型提供了更精细的控制空间。

需要明确，此阶段两者是协同关系：主动检查负责“基础存活判定”，被动检查负责“业务质量判定”。

千万 QPS 阶段：被动检查为主，主动检查兜底

进入千万 QPS 级别，后端节点可达数千甚至上万台，负载均衡实例扩展到数百台。架构面临新挑战，也获得了新条件。

挑战一：主动探测的规模开销
假设 200 台负载均衡实例，5000 台后端节点，每台独立以 5 秒间隔探测，每秒产生的探测请求量为：

200 × 5000 / 5 = 200,000 次/秒

这个数字本身相对于千万业务流量占比很低，但关键问题在于投入产出比。这些轻量级探测难以发现灰色故障，检测能力与资源投入不成正比。

挑战二：健康状态一致性
数百台负载均衡实例各自独立判定，容易出现状态不一致，导致流量分布不均甚至局部过载。

挑战三：检测精度要求提升
每秒千万次请求，即使0.1%的误判率，也意味着每秒有上万次请求被误路由。精度和响应速度要求极高。

新条件：被动检查的统计信号已充分可靠
在千万 QPS 下，每个后端节点每秒处理的真实请求量足够大（通常在千次以上）。被动检查拥有充分的样本量，统计窗口可缩短至秒级，灵敏度远优于分钟级间隔的主动探测，且检测的是真实业务表现。

架构应对：

1. 被动检查升级为主要检测手段。 海量真实流量本身就是最理想的“探针”。
2. 主动检查收缩为兜底机制。 职责收缩至检测零流量节点（新上线/长期无流量）和作为被动检查的交叉验证。探测频率可大幅降低，并采用集中式架构控制规模。
3. 引入集中式健康状态管理。 由专门的健康检查服务汇总各实例上报的被动检查数据和少量主动探测结果，统一计算健康状态并下发，解决状态一致性和全局视角问题。

下图展示了千万 QPS 级别的典型健康检查架构：

04 关键设计维度对比

下表从关键维度对比了三个阶段健康检查架构的核心差异：

05 深入：被动检查的关键设计考量

当被动检查在千万 QPS 阶段成为主力后，其自身的设计质量至关重要。

横向对比 vs 绝对阈值

被动检查的判定逻辑主要有两种思路：

• 绝对阈值：为错误率、P99延迟等设定固定阈值，超过即判异常。简单直接，但难以适应不同时段、不同业务高峰的正常水位波动。
• 横向对比：将同一组节点的指标互相对比，标记显著偏离整体水平的节点为异常。优势在于天然适应业务波动，只关注“谁明显比别人差”，对全局波动抗干扰能力强。

在实践中，两者常结合使用：横向对比作为主要判定依据，绝对阈值作为所有节点都不健康等极端情况下的兜底。

统计窗口设计

被动检查依赖统计推断，统计窗口的长度是核心权衡：

• 窗口太短：样本量不足，易因偶发波动误判。
• 窗口太长：检测延迟增大，故障节点发现晚。

在千万 QPS 下，单节点流量充足，窗口通常可缩短至 5~10 秒，配合滑动窗口平滑波动。而在百万 QPS 阶段，部分低流量节点可能需要30秒甚至更长窗口，这也是该阶段仍需主动检查补充的原因之一。

被动检查的局限性

被动检查并非万能，需正视其固有限制：

• 零流量盲区：对新上线或长期无流量的节点无感知。这是主动检查作为兜底不可或缺的根本原因。
• 局部故障检测困难：若节点仅对特定请求异常，异常信号会被整体指标稀释，检测灵敏度下降。
• 流量不均导致的统计偏差：采用加权轮询等策略时，低权重节点样本不足，需更长窗口，影响实时性。

这些局限恰恰说明了被动与主动检查是 “主次协同” 而非简单的替代关系。

亚健康节点的处理策略

被动检查的核心价值之一是能发现“亚健康”节点。如何处理它们直接关系到系统稳定性。

最常见策略是渐进式降权：一个被判定为亚健康的节点，其流量权重逐步降低（如从100%降至50%、20%），而非直接摘除。这样做有两个好处：

1. 避免流量突然转移导致其他节点过载。
2. 保留观察窗口，若节点恢复则权重可逐步回升；若持续恶化则最终摘除。

下图展示了包含“观察期”的完整节点状态流转过程，这能避免节点刚恢复就承受满负荷流量导致的性能抖动：

06 健康检查与熔断器的边界

在工程中，健康检查与熔断器（Circuit Breaker）易被混淆，因都涉及检测后端异常。厘清边界有助于更好设计系统。

两者的核心区别在于作用层级和决策目标不同：

简而言之，健康检查解决 “流量分发给谁” 的全局路由问题；熔断器解决 “这次调用是否继续” 的瞬时决策问题。在千万 QPS 架构中，两者协同工作：健康检查在负载均衡层管理节点流量配比，熔断器在客户端侧为单次请求提供快速失败保护。

07 集中式健康服务的设计要点

千万 QPS 架构引入的集中式健康检查服务是关键组件，其设计需考量以下几点：

• 数据聚合方式：健康服务需将数百台 LB 实例上报的分散观测数据（各节点的错误率、延迟等）聚合为全局健康画像。聚合时需考虑各实例与节点间的流量权重差异，给予流量大的实例更高的观测权重。
• 状态下发机制：采用推拉结合。常规状态更新通过实例周期性拉取（如每秒一次）；紧急状态变更（如节点宕机）通过服务主动推送即时通知。
• 容错设计：集中服务本身必须高可用（多副本部署）。同时，每个 LB 实例需具备降级能力：本地缓存最近健康状态，并保留独立被动检查能力。当集中服务不可用时，回退到本地判定模式，虽然可能出现短暂不一致，但系统不会完全失去故障检测能力。这在 运维/SRE 实践中是保障系统韧性的关键设计。

08 总结

健康检查架构的演进，是由规模驱动的自然选择，其核心驱动力是应对“灰色故障”。

• 十万 QPS：节点少，灰色故障罕见，主动探测简单高效。
• 百万 QPS：灰色故障常见，被动检查开始发力，与主动检查协同，健康状态扩展为多级模型。
• 千万 QPS：真实流量统计信号充分可靠，被动检查上升为主力，主动检查退化为兜底，并引入集中式管理解决一致性问题。

这个演进过程揭示了一个核心设计哲学：当每个节点每秒都有成千上万的真实请求经过时，这些请求本身就是最丰富、最准确、最及时的健康“探针”。 让真实流量成为健康检查的主要信号源，而不仅依赖额外模拟探测，是构建千万 QPS 高可用架构的必然路径。

关于更多 TCP/IP 及高并发架构的深度讨论，欢迎在技术社区持续交流。

本期内容视频解读：