什么叫熔断

　　当流量从百万跨越到千万量级，熔断不再是一个“开关”，而是一套分层协作的决策体系。

一、从一个典型故障说起

　　场景还原

　　某个工作日下午，一个核心服务的缓存集群正在做扩容。扩容期间，缓存命中率短暂下降，大量请求穿透到数据库层。数据库延迟从 5ms 上升到 200ms，但并没有返回错误。

　　服务的全局错误率依然是 0%，熔断器纹丝不动。但实际上，200ms 的延迟已经导致上游调用方的连接池逐渐耗尽，排队请求越积越多。10 分钟后，连接池溢出引发了连锁故障，波及了 3 个上游服务。

　　熔断器为什么没有起作用？因为故障不是“错误”，而是“变慢”。经典熔断器只看错误率，对延迟恶化视而不见。

　　这是一个真实场景的简化描述。在十万 QPS 量级，这种延迟型故障的影响范围有限，人工介入通常来得及。但在千万 QPS 量级，10 分钟足以造成数百万次请求的体验劣化，熔断策略必须能够识别和应对多种类型的故障。

　　本文将从经典的三态熔断器出发，沿着 QPS 量级的增长，讲述熔断策略如何从“简单的错误率开关”演进为“多层级、多维度的协同决策体系”。

二、经典三态熔断器：起点

　　经典熔断器遵循“关闭、打开、半开”的三态模型，核心逻辑是统计一段时间窗口内的错误率，超过阈值就触发熔断。

　　经典熔断器的三态流转：错误率超过阈值时断开，经过冷却期后进入半开状态试探恢复。

　　图 1：经典三态熔断器状态机

　　这个模型在十万 QPS 量级下工作良好。此时下游服务的实例数通常在个位数到数十个之间，一个全局的错误率统计基本可以反映下游的真实健康状况。熔断器的“开”和“关”是针对整个下游服务的，逻辑简单、行为可预测。

　　但这个模型有两个隐含假设：第一，故障表现为“请求失败”，即错误率上升；第二，下游服务的健康状态是“整体一致”的，要么都正常、要么都异常。当流量规模增长后，这两个假设都会被打破。

三、百万 QPS：从服务级到实例级3.1 全局错误率的失真

　　当下游服务扩展到数百个实例时，全局错误率统计会产生两类典型问题。

　　第一类是少量坏节点被多数健康节点“稀释”。假设下游有 200 个实例，其中 3 个因为磁盘 IO 问题导致超时率 80%，但其余 197 个实例完全正常。全局错误率可能只有 1.2% 左右，远低于熔断阈值，熔断器始终处于关闭状态，这 3 个坏节点会持续接收流量并拖慢部分请求。

　　第二类是个别严重故障节点拉高全局错误率导致误判。如果某些节点因为 OOM 导致 100% 失败，同时请求分配不均匀，这些节点承担了较多流量，全局错误率可能短暂突破阈值，触发对整个下游服务的熔断，误伤了原本健康的 190 多个节点。

　　全局错误率的两种失真：坏节点被“稀释”导致漏判，或被“放大”导致误判。

　　图 2：全局熔断 vs 实例级熔断

3.2 实例级健康检测

　　百万 QPS 场景下的解决思路是：将熔断的粒度从“服务”下沉到“实例”。调用方为每个下游实例独立维护健康状态，当某个实例的错误率或响应时间持续异常时，将其从负载均衡池中临时摘除。

　　实例级熔断配合主动健康检查和被动异常检测，能有效处理百万 QPS 量级下的常见故障场景。大部分情况下，服务故障确实是局部的，少数节点出问题，实例级摘除就足够了。

　　但这一阶段的熔断本质上还是“单层”的，只是粒度从服务细化到了实例。它有一个前提：故障是离散的，表现为个别实例的异常。当故障的性质发生变化，不再是个别实例出问题，而是“一片区域变慢”“一个集群行为异常”时，单层的实例级熔断就会遇到新的挑战。

四、千万 QPS：分层熔断体系4.1 故障模式的质变

　　千万 QPS 系统通常有数千个服务实例，分布在多个集群、多个可用区。典型的一次请求可能经过接入层、网关层、业务逻辑层、数据层等多个环节。在这样的体系中，故障的表现形式远比“某个实例挂了”要复杂。

　　根据故障的影响范围，可以归纳为几类典型模式：

　　千万 QPS 系统面临的故障不再是单一维度的，而是在不同层级呈现不同的模式和影响范围。

　　图 3：不同层级的故障模式

　　实例级故障：单个实例的硬件异常、进程 hang 住等，影响范围最小，发生频率最高。

　　集群级故障：某个集群的部署变更引入了 bug，或集群内的共享存储出现性能退化。特征是该集群内多个实例同时表现异常，但其他集群不受影响。

　　可用区级故障：某个可用区的交换机出现丢包，或该区域的云服务商底层设施出现问题。表现为该可用区内的多个不相关服务同时受影响。

　　服务级故障：下游服务整体不可用，所有集群、所有可用区都受影响。通常由公共依赖崩溃或配置全量推送错误引起。

　　这些故障发生在不同的“层级”，影响的范围和程度各不相同。仅靠实例级熔断，面对集群级或可用区级的故障时，要么反应太慢（需要逐个摘除大量实例后才能感知到问题的规模），要么判断不准确（无法区分“很多实例各自出了问题”和“它们因为共同原因一起出了问题”）。

4.2 分层熔断的架构设计

　　分层熔断的核心思想是：在不同的层级设置独立的熔断决策点，每层负责识别和处理该层级范围内的故障，各层之间协同工作。

　　分层熔断在实例、集群、可用区、服务四个层级分别部署独立的熔断决策逻辑，逐层收敛故障影响范围。

　　图 4：千万 QPS 下的分层熔断体系

　　实例层熔断：最底层的防线，针对单个实例的异常指标做判断，将故障实例从负载均衡池中摘除。它处理的是最常见、最局部的故障。

　　集群层熔断：当一个集群中的多个实例同时出现异常时，集群层熔断介入。它不再逐个摘除实例，而是对该集群整体降低流量权重或暂停分配。这类故障通常由部署变更、配置推送或集群内共享资源异常引起。

　　可用区层熔断：当某个可用区的网络质量下降或基础设施出现问题时，该可用区内的多个服务和集群可能同时受影响。可用区层熔断负责将流量从受影响的可用区调度到其他健康可用区。

　　服务层熔断：最上层的保护机制。当整个下游服务的可用性严重下降时，触发降级策略：返回缓存数据、默认值，或者直接快速失败，避免上游被拖垮。

4.3 分层的核心价值：精确降级

　　对比没有分层时故障扩散到全局，和有分层时故障被控制在局部范围内的效果差异。

　　图 5：故障传播对比：无分层 vs 分层熔断

　　分层熔断的核心价值在于将故障的影响范围控制在其发生的层级。可用区级别的网络抖动，由可用区层熔断处理，不需要触发服务级别的全量降级；某个集群的部署问题，由集群层处理，不会影响其他集群的正常流量。

　　在千万 QPS 下，“精确降级”比“是否降级”更重要。全量熔断一个核心下游服务的代价非常高，可能直接影响千万量级用户的体验。分层熔断提供了在不同粒度上做精确决策的能力，尽可能在保障系统稳定的同时减少业务损失。

五、灰色故障：分层熔断的真正考验

　　在实际生产环境中，最棘手的并不是某个实例彻底挂掉（这种反而容易识别），而是灰色故障：服务没有完全不可用，但行为明显异常。比如延迟从 10ms 上升到 500ms，或者错误率在 1%-5% 之间波动，又或者间歇性超时。

5.1 灰色故障的识别困难

　　灰色故障对经典熔断器构成了严峻挑战。它们通常不会触发基于固定阈值的熔断，因为指标“看起来还行”。但在千万 QPS 下，即使 1% 的请求延迟劣化，也意味着每秒有 10 万次请求受到影响。

　　分层熔断体系通过在不同层级使用不同的检测维度来应对灰色故障：实例层关注单实例的延迟分位数（如 P99），集群层关注集群间的指标对比（某个集群的 P99 是否显著偏离其他集群），可用区层关注跨区的整体延迟分布差异。通过“横向对比”而非“固定阈值”来识别异常，可以更灵敏地发现灰色故障。

　　灰色故障的典型表现：指标没有越过固定阈值，但在同层级横向对比中明显偏离正常范围。

　　图 6：灰色故障的检测思路：横向对比 vs 固定阈值

5.2 多维指标的必要性

　　回到开篇的场景：缓存扩容导致延迟上升，错误率为 0%。这种故障只看错误率永远不会被熔断。千万 QPS 下的熔断决策需要综合多个维度的指标：

　　错误率反映的是“请求是否成功”，延迟反映的是“请求是否及时”，排队深度反映的是“服务是否还有处理能力”。单一指标在特定场景下都可能失灵，多维指标的交叉验证可以减少漏判。比如当延迟上升但错误率为 0 时，如果同时观察到排队深度在持续增长，就可以更有信心地判断服务正在走向过载。

　　需要说明的是，多维指标并非千万 QPS 的专属。百万 QPS 系统也可以引入多维度判断。但在千万 QPS 下，由于故障的影响被放大、容错时间窗口更短，多维指标从“有则更好”变成了“不可或缺”。

六、分层协同与实践挑战6.1 自下而上的信号聚合

　　各层熔断器不是孤立工作的。底层的异常信号是上层决策的输入。当实例层频繁摘除同一集群中的实例时，集群层会收到这个信号，评估是否需要对该集群整体做熔断。类似地，当多个集群的健康状态同时恶化，且集中在同一个可用区时，可用区层会据此判断是否存在区域性故障。

　　这种自下而上的聚合，让上层熔断器可以基于更全面的信息做出宏观决策，而不是仅依赖自身的直接观测。

6.2 自上而下的策略调整

　　上层的决策也会反向影响下层的行为。当可用区层判定某个区域不健康并调走流量后，该区域内的集群层和实例层可以相应调整自己的判断阈值，比如放宽半开状态的试探频率，减少不必要的探测流量。

　　分层熔断中信号自下而上聚合、策略自上而下调整，形成双向协同闭环。

　　图 7：分层熔断的双向协同

6.3 层间冲突与优先级

　　分层设计需要注意层间决策的一致性。如果实例层刚把某个节点标记为恢复，而集群层同时判定该集群需要熔断，就可能出现冲突。通常的原则是上层优先级高于下层：如果集群层决定熔断整个集群，即使某些实例在实例层看来已经恢复，也应暂缓恢复流量，等集群层确认安全后再逐步放量。

6.4 重试风暴：恢复阶段的隐患

　　分层熔断在恢复阶段有一个容易被忽视的风险：当多个调用方同时进入半开状态，试探流量叠加可能形成新的压力脉冲。

　　在百万 QPS 场景下，调用方数量有限，半开试探的流量相对可控。但在千万 QPS 下，可能有数百个调用方实例同时等待对下游的熔断恢复。如果它们的冷却时间接近，就会在差不多的时刻集中发送试探请求。下游刚从故障中恢复，还没来得及预热，就被这波试探流量再次打垮。

　　应对这个问题的思路包括：在冷却时间中加入随机抖动（jitter），避免集中试探；由集群层或可用区层统一协调恢复节奏，而不是让每个调用方独立决定。恢复策略需要和熔断策略同样被认真对待。

6.5 可观测性：分层熔断的运维基础

　　分层熔断增加了系统的复杂度，排查问题的难度也随之上升。当一个请求失败时，需要回答的不再是“是不是被熔断了”，而是“被哪一层熔断了，基于什么指标，在什么时间点触发的”。

　　没有完善的可观测性支撑，分层熔断反而可能成为排障的障碍。每一层的熔断决策都需要记录触发原因、影响范围和持续时间，并能在全链路追踪中被关联和查询。这不是可选项，而是分层熔断能够在生产环境中稳定运行的前提。

七、技术演进总结

　　从十万 QPS 到千万 QPS，熔断策略的粒度、层次和检测维度随规模逐步递进。

　　图 8：熔断策略演进路线

八、写在最后

　　熔断策略的演进，本质上反映了故障模型从简单到复杂、从单一到多层的变化。十万 QPS 时，故障是“服务挂了”；百万 QPS 时，故障是“某些实例不太正常”；千万 QPS 时，故障可能是“某个可用区的网络在抖动，某个集群刚发布了新版本，同时某个共享缓存在做扩容”，这些问题可能同时发生、相互叠加。

　　分层熔断不是万能的，它增加了系统的复杂性和运维成本。对于流量较小的系统，经典的三态熔断器或实例级熔断已经足够好用。只有当系统规模增长到故障模式本身变得“分层”时，熔断策略才需要对应地“分层”。

　　同时也要认识到，分层熔断不是孤立存在的。在千万 QPS 系统中，它需要和限流、降级、重试控制等机制协同工作，共同构成系统的整体韧性。熔断解决的是“快速止血”，但止血之后的降级方案、恢复路径和容量规划，同样是系统稳定性的关键环节。