目录
一、先把"熔断"这个词拆开
（一）一次级联故障的完整放大链
1、慢比错更危险：资源占用的乘法
2、重试、超时与线程池：三个放大器
3、故障的传染路径：从一个实例到整张调用图
（二）熔断器的定位：它是什么，更重要的是它不是什么
1、与限流、降级、隔离舱、摘除的边界
2、熔断器的收益与代价：一笔必须算清的账
（三）设计前必须填掉的三处留白
二、状态机：从三态模型到可落地的状态机
（一）经典三态与它省略的东西
1、关闭、打开、半开的职责
2、被省略的第四态与第五态
（二）状态跃迁的四个判定点
1、关闭到打开：阈值判定
2、打开到半开：等待窗口与退避
3、半开到关闭或打开：探测判定
4、并发安全与惊群
三、判据设计：怎么定义"失败"
（一）失败的分类：不是所有异常都该计入
1、业务异常与系统异常必须分开
2、调用方错误与四百类响应
3、超时的归属与取消语义
（二）慢调用：比错误率更早的信号
1、慢调用率与响应时间阈值
2、平均耗时的陷阱与分位数选择
（三）统计口径：滑动窗口的两种实现
1、计数窗口与时间窗口
1.1 计数窗口
1.2 时间窗口
1.3 选型建议
2、环形数组与桶的实现细节
3、最小请求数：低流量下的最后一道闸
4、状态切换时的窗口重置
四、恢复：半开是整个设计里最危险的一段
（一）探测流量的三种放法
1、单请求、固定名额与比例放行
2、自适应节流：把"开关"变成"旋钮"
（二）等待窗口：固定、退避与抖动
1、固定窗口的同步共振
2、指数退避、上限与抖动
（三）恢复判定与二次熔断
1、探测样本量与判定标准
2、翻转抑制与冷却期
3、主动健康探测与被动统计的配合
五、粒度与位置：熔断器挂在哪一层
（一）四种粒度的取舍
1、服务级、接口级、实例级与参数级
2、粒度过粗与过细各自的失效方式
（二）客户端、服务端与网格：三处部署位置
1、客户端熔断
2、服务端自保护
3、服务网格与代理层
（三）分布式状态：本地统计还是全局统计
1、本地统计的偏差与它的优点
2、全局统计的诱惑与代价
六、与其他治理手段的协同
（一）熔断与重试：最容易互相拆台的一对
1、重试放大与重试预算
2、顺序问题：熔断在重试之内还是之外
（二）熔断与超时：预算切分
1、没有超时就没有熔断
2、超时预算的逐层切分与截止时间传递
（三）熔断与降级：断开之后返回什么
1、四类兜底策略及其风险
1.1 静态默认值或空集合
1.2 缓存的历史数据
1.3 切换到备用链路
1.4 显式失败
2、兜底本身的可靠性
3、什么时候不应该降级
（四）熔断与隔离舱、限流、负载均衡
1、隔离舱限定爆炸半径
2、自适应限流与熔断的分工
3、异常点检测与负载均衡的配合
七、参数怎么定：从拍脑袋到有据可依
（一）参数集与它们之间的耦合
1、核心参数清单
2、参数之间的相互约束
（二）用数据定阈值的三种方法
1、从基线分布反推
2、压测与故障注入标定
3、按流量档位分级配置
（三）配置治理
1、动态下发与灰度
2、审计、回滚与默认值
八、可观测性：熔断器必须能自证
（一）必须暴露的指标
1、指标清单
2、维度与基数控制
（二）事件、日志与告警
1、状态跃迁事件
2、告警的分层
（三）一条十分钟收敛的排查路径
九、测试与演练
（一）单元测试：把时间变成可注入的参数
1、虚拟时钟
2、表驱动的状态机测试
（二）集成测试与故障注入
1、故障注入的四种形态
2、演练脚本与验收标准
（三）上线前的自检清单
十、答题范式与失分点
（一）三种时间长度下的作答
1、三分钟版本
2、十分钟版本
3、四十分钟版本
（二）十二个高频失分点
（三）结论
参考资料
模式与理论
站点可靠性工程实践
框架实现
代理与服务网格
重试与流量协同
中文实践资料
干货分享，感谢您的阅读！
熔断器是一道被严重低估的设计题。多数人能在三十秒内画出"关闭、打开、半开"三个圈和几条箭头，然后就没有然后了——而真正决定这套机制在生产环境是救命还是要命的，恰恰是三个圈之外的东西：什么样的失败才算失败、统计窗口怎么切、低流量时怎么防止误判、半开阶段放多少探测流量、探测失败后等多久再试、熔断器该挂在服务上还是实例上、多个副本各自统计出的不一致视角要不要收敛、断开之后返回什么、这些参数凭什么定成这个数。
本文把这道题从一张状态图展开成一套可落地的工程方法：先说清熔断器在治理体系里的确切位置与它必须付出的代价，再逐层推到判据分类、滑动窗口实现、半开探测与退避、粒度与部署位置、分布式统计口径、与重试和超时的协同、参数标定方法、可观测性与演练，最后给出三种时间长度下的作答范式与十二个高频失分点。
熔断器的价值不在于"能断开"，而在于它在正确的时刻、以正确的粒度、断开正确的时长，并且在断错的时候能被人快速看见和纠正。
一、先把"熔断"这个词拆开
（一）一次级联故障的完整放大链
1、慢比错更危险：资源占用的乘法
谈熔断器之前，必须先谈清楚它要挡住的是什么。工程直觉里，"依赖挂了"是最坏的情况，但在真实的线上事故复盘里，把整条链路拖垮的往往不是彻底不可用的依赖，而是变慢的依赖。
原因在于资源占用是一道乘法题。一个同步调用链上的服务，其并发承载能力大致等于工作线程数除以单次请求耗时。假设某服务有 200 个工作线程，正常情况下一次请求耗时 20 毫秒，那么它的理论吞吐是每秒一万次。现在下游某个依赖从 20 毫秒劣化到 2 秒——注意它并没有报错，只是慢了一百倍——同样的 200 个线程，吞吐立刻掉到每秒一百次。上游的请求并不会因此减少，它们会在队列里堆积，堆到队列满，然后线程全部被占住，健康检查接口也响应不了，负载均衡开始把这个实例摘掉，剩余实例承接更多流量、更快耗尽线程，摘除进一步扩散。
彻底不可用的依赖反而更"友好"：连接被立刻拒绝，调用方在几毫秒内拿到错误，线程迅速归还。慢依赖不给这个机会，它把调用方的资源以一种缓慢而稳定的方式吃干净。所以一套只看错误率、不看响应时间的熔断器，在最危险的那类故障面前是失灵的——这是后文判据设计里必须专门处理的一件事。
2、重试、超时与线程池：三个放大器
在慢依赖这个初始扰动之上，系统里通常还叠着三个放大器，它们会把一次局部劣化推成全局故障。
第一个是重试。假设链路是 A 调 B、B 调 C，A 和 B 各自配了"失败重试两次"。当 C 开始超时，B 对 C 的一次逻辑调用变成三次物理调用，A 对 B 的一次逻辑调用又变成三次，于是 C 实际承受的流量是原始流量的九倍。C 本来只是有点慢，被九倍流量一压就彻底趴下；趴下之后失败更多、重试更多，形成正反馈。这就是"重试风暴"的典型成因：一个被广泛推荐的可靠性手段，在故障期间变成了压垮系统的主力。
第二个是超时。超时设置得过长，等价于把线程主动送给慢依赖占用；超时设置得过短，会把本来能成功的请求判成失败并触发重试，同样放大流量。更常见的问题是超时预算根本没有沿链路切分：A 给自己设了 3 秒超时，B 给自己也设了 3 秒，C 又设了 3 秒，结果 A 早已放弃、把结果返回给用户，B 和 C 还在为一个不会有人接收的结果消耗资源——这部分工作量在监控上表现为"负载很高但吞吐很低"，是最难解释的一类现象。
第三个是共享资源池。当多个不同的下游依赖共用同一个线程池、连接池或数据库连接时，其中任何一个变慢，都会把整个池子占满，进而拖垮那些依赖健康服务的调用。这是隔离舱模式要解决的问题，也是熔断器必须配合的前提：如果资源没有隔离，熔断某一个依赖并不能阻止它的影响外溢到其他调用路径上。
3、故障的传染路径：从一个实例到整张调用图
把上面三层叠加起来，就得到了级联故障的完整传染路径：某个下游实例因为垃圾回收停顿、慢查询、缓存击穿或者热点分片，响应时间抬升；调用方线程被占用，超时触发重试，下游压力放大；下游更多实例进入劣化，负载均衡摘除部分实例后，剩余实例承接的流量密度更高，劣化速度更快；调用方自身的响应时间随之抬升，它的上游开始重复同样的过程；最终整张调用图上与这条路径相连的服务全部不可用，而最初的扰动可能只是一个实例的一次垃圾回收。
熔断器要切断的就是这条链条上"调用方持续把资源投给一个已经没有希望的依赖"这一环。它的作用不是修复下游，而是保护上游，顺带给下游一个不被持续冲击的喘息窗口。
（二）熔断器的定位：它是什么，更重要的是它不是什么
1、与限流、降级、隔离舱、摘除的边界
治理手段之间的混淆是这道题最常见的失分点。把边界画清楚，后面的设计才不会互相打架。
熔断器是调用方视角的、基于统计的、自动的快速失败开关。它的判断依据是"我最近调用这个依赖的结果分布"，它的动作是"接下来一段时间我不再发起这类调用，直接在本地失败"。关键词有三个：调用方视角、统计驱动、自动恢复。
限流是被调方视角的准入控制，它的判断依据是"我当前的负载和配额",动作是拒绝超出部分的请求。限流保护的是自己，熔断保护的是调用者。两者方向相反，经常被同时需要，但不能相互替代：限流无法阻止上游持续发起注定失败的调用，熔断也无法保证被调方不被打垮。
降级是业务视角的替代方案，它回答的是"这个能力不可用时，产品体验上如何退让"。降级可以由熔断触发，也可以由人工开关触发，还可以由容量预案触发。熔断是"要不要发起调用"的技术判断，降级是"不发起调用之后给用户看什么"的业务判断——把二者混为一谈，会导致设计里出现"熔断了但没想好返回什么"这种半成品。
隔离舱是资源视角的分割，把不同依赖的线程、连接、内存配额分开，确保一个依赖的故障不会耗尽全局资源。它和熔断是互补的：隔离舱限定爆炸半径，熔断缩短爆炸时间。
实例摘除（异常点检测）是负载均衡视角的动作，它把统计上表现异常的后端实例临时从可用列表中移出。它和熔断在实现上高度相似，但语义不同：摘除是"换一个实例继续调用"，熔断是"不再调用这个依赖"。当一个依赖的多数实例都健康、只有个别实例异常时，正确动作是摘除而非熔断；当整个依赖集群都不可用时，摘除无处可换，才轮到熔断。
2、熔断器的收益与代价：一笔必须算清的账
熔断器不是免费的可靠性。它的收益很清楚：在依赖不可用期间，把调用方的资源从注定失败的等待中解放出来，避免线程池耗尽与级联传染；同时降低对故障依赖的冲击，给它恢复的机会；此外，本地快速失败把失败延迟从"超时时长"压缩到"微秒级"，用户等待时间显著下降。
代价同样清楚，而且经常被回避。第一，它会主动放弃一部分本来可能成功的请求——熔断打开期间，即使下游已经恢复，在下一次探测之前的所有请求都会被拒绝，这是确定性的可用性损失。第二，它引入了一个新的、有状态的判断组件，这个组件本身可能出错：阈值配置错误会导致大面积误熔断，状态机的并发缺陷会导致状态卡死，统计窗口的内存占用在高基数场景下会引发新的问题。第三，它增加了系统的认知复杂度，故障排查时需要额外回答"这次失败是真实失败还是熔断拒绝"。
因此判断一个场景该不该上熔断器，可以用三个条件筛：调用是否跨越了故障隔离边界（跨进程、跨机房、跨供应商）；失败是否具有持续性（瞬时抖动不需要熔断，持续故障才需要）；失败之后是否有可接受的兜底路径。三个条件里缺任何一个，熔断器带来的可能是净损失。特别地，对本地内存计算、对确定性极强且延迟极低的本地缓存调用加熔断，几乎总是过度设计。
（三）设计前必须填掉的三处留白
一句"设计一个熔断器"里藏着三处必须先填的空。顺序不能颠倒：填不完这三处，写出来的状态机只是一张示意图。
第一处是熔断谁——资源粒度。是熔断整个下游服务，还是熔断到某个接口，还是熔断到某个具体实例，甚至熔断到某个参数分片（比如某个商户号、某个分库）？粒度选择直接决定了统计样本量、误熔断概率与内存占用，也决定了熔断动作的语义。
第二处是按什么判——判据与统计口径。哪些结果算失败？慢算不算失败？统计窗口是按次数还是按时间？窗口多长？最少多少样本才允许判定？这一组问题的答案共同构成"健康度"的定义，而熔断器本质上就是一个健康度的自动开关。
第三处是断多久、怎么回——恢复策略。打开状态维持多久？探测放多少流量？探测成功几次才算恢复？探测失败后是重置等待时长还是指数拉长？这一组问题决定了熔断器在"依赖已恢复但我还不知道"和"依赖没恢复但我又打过去了"之间的权衡，也是整套设计里最容易出事、最少被认真对待的部分。
后文按照"状态机—判据—恢复—粒度与位置—协同—参数—可观测—演练"的顺序展开，每一节都给出可以直接写进设计评审文档的结论。
二、状态机：从三态模型到可落地的状态机
（一）经典三态与它省略的东西
1、关闭、打开、半开的职责
三态模型是这道题的公共起点，但每个状态的职责需要说得比"通过/不通过"更精确。
关闭态是常态。请求正常放行，同时每一次调用的结果（成功、失败、耗时）都被记录进统计窗口。关闭态的核心职责不是放行，而是采样——放行是默认行为，采样才是它存在的理由。这里有一个容易被忽略的点：关闭态下熔断器仍然要为每次调用付出统计成本，因此统计结构的性能开销必须控制在可忽略的量级，否则熔断器会在没有故障的百分之九十九点九的时间里成为系统的税负。
打开态是保护态。所有请求不经过网络直接失败，返回一个明确可识别的"被熔断"信号，同时不再采集被调方的健康数据——因为根本没有调用发生。打开态的核心职责是计时：它必须知道自己什么时候该结束。这里的关键设计是打开态不应该采集统计数据，因为本地拒绝的结果不反映依赖的真实健康度，把它们计入窗口会让熔断器永远出不来。
半开态是试探态。它按某种策略放行少量请求，用真实流量探测依赖是否恢复，并根据探测结果决定回到关闭还是退回打开。半开态是整套机制里风险最高的一段：放得太多，等于把刚喘过气的下游再打一次；放得太少，恢复判定的统计置信度不足，容易误判。它同时也是并发控制最复杂的一段，因为"名额"这个概念只在这里出现。
2、被省略的第四态与第五态
生产级的熔断器几乎都不止三个状态。至少还有两个必须显式建模的状态，另外一个则值得考虑。
强制打开态与强制关闭态是运维必需品。强制打开用于人工确认下游不可用时的主动隔离，比如上游已经知道下游在做破坏性变更，不希望等统计窗口自己发现；强制关闭（也叫熔断器禁用）用于人工确认熔断器误判时的紧急放行，比如阈值配错导致大面积误熔断，需要立刻恢复流量而来不及改配置发布。这两个状态的关键约束是：它们不参与自动跃迁，只能由人工或配置中心切回自动模式。缺了这两个状态，线上出问题时唯一的手段就是发版，这在故障处置窗口里是不可接受的。
预热态（或称冷启动态）用于处理实例刚启动、连接池未建立、即时编译未完成、缓存未加载时的响应时间天然偏高的问题。如果不做特殊处理，一个刚扩容出来的实例可能在头几十秒内因为慢调用比例超标而把自己熔断掉，进而导致扩容失效——这是自动扩缩容与熔断器组合时的一个真实陷阱。处理方式可以是启动后一段时间内不判定，也可以是把阈值随运行时长线性放宽。
（二）状态跃迁的四个判定点
1、关闭到打开：阈值判定
从关闭跃迁到打开需要同时满足两组条件，缺一不可。
第一组是样本量条件：统计窗口内的调用次数必须达到最小请求数阈值。这是低流量场景下防止误判的唯一屏障——一个每分钟只被调用三次的接口，如果不设最小请求数，两次失败就是百分之六十六的失败率，会立刻触发熔断，而这两次失败很可能只是一次网络抖动。
第二组是比率条件：失败率或慢调用率超过阈值。这里推荐用比率而非绝对次数，因为比率对流量规模不敏感，同一套阈值可以在不同流量档位上复用。绝对次数阈值（比如"一分钟内失败 50 次"）在流量翻倍时会变得过于敏感，在流量腰斩时又会变得迟钝。
一个实现层面的重要细节：判定应当在每次调用结果记录之后立即进行，而不是靠一个定时任务周期性扫描。定时判定会引入最长等于扫描周期的检测延迟，在故障爆发的头几秒里，这个延迟意味着成千上万次本可以避免的调用。
2、打开到半开：等待窗口与退避
从打开跃迁到半开由时间驱动。经典实现是"打开后固定等待 N 秒进入半开"，这个方案在单实例场景下没问题，在多实例场景下会制造同步共振——同一时刻打开的几百个副本，会在同一时刻一起进入半开，一起放出探测流量，把刚刚有所恢复的下游再次打死，然后一起退回打开，形成周期性的脉冲攻击。
正确做法有两层：第一层是等待时长随连续失败的探测轮次指数增长，并设置上限（比如从 5 秒起，每次翻倍，封顶 60 秒）；第二层是给等待时长叠加随机抖动（比如在计算值上乘以 0.8 到 1.2 之间的随机因子），把不同副本的探测时刻打散。这两层的组合能显著削平脉冲。
另一个实现细节是跃迁的触发方式。惰性跃迁（下一次请求到来时才检查是否该进入半开）比定时器跃迁更简单也更省资源，且不会在没有流量时空转；代价是如果长时间没有请求，熔断器会一直停留在打开态的数据结构上，直到下一次请求触发状态检查。绝大多数场景下惰性跃迁是更好的选择。
3、半开到关闭或打开：探测判定
半开态的判定需要回答两个问题：放多少探测请求，以及用什么标准判定成功。
最简单的方案是放行单个请求，成功即关闭、失败即打开。它的优点是对下游冲击最小，缺点是统计置信度极低——一次成功可能只是运气，下游可能只是恰好处理了这一个轻量请求。这个方案适合下游恢复代价极高、宁可慢一点也不能再冲击的场景。
更常见的方案是固定名额：半开期间允许 N 个请求通过（比如 10 个），统计这 N 个请求的失败率，低于阈值则关闭，否则打开。这个方案在冲击可控与置信度之间取得了平衡，是主流框架的默认策略。要注意名额是并发名额还是累计名额：并发名额意味着同时最多 N 个在途请求，累计名额意味着本轮半开总共只放 N 个。前者在高并发下会放出远超 N 个请求，必须明确。
最稳妥的方案是渐进放量：半开后不是一次性放开固定名额，而是按时间逐步抬升放行比例，比如第一秒放 1%，第二秒放 5%，然后 10%、30%、100%，每一档都检查失败率，任何一档不达标就退回打开。这个方案对下游最友好，实现复杂度也最高，适合核心链路上恢复代价极高的依赖。
4、并发安全与惊群
状态机的并发正确性是熔断器实现里最容易出隐蔽缺陷的地方，因为它的错误往往只在故障期间的高并发下才暴露，而那正是最不想调试的时刻。
半开名额的分配必须是原子的。典型实现是用一个原子整数做名额计数，通过比较并交换获取名额；获取失败的请求直接按熔断处理。这里的常见缺陷是名额只减不还：如果请求在执行过程中抛出未捕获的异常、或者调用方线程被中断，名额没有归还，半开态就会永久卡住——所有后续请求都拿不到名额，熔断器既回不到关闭也不再重新打开。修复方式是把名额归还放进等价于 finally 的清理逻辑里，并给半开态本身加一个最大停留时长作为兜底，超时未完成判定就强制退回打开重新计时。
状态跃迁本身也必须是原子的。多个线程可能同时观察到"失败率超阈值"并同时尝试把状态从关闭改成打开。如果用简单的读—判断—写，会出现重复跃迁，进而重复发出状态变更事件、重复重置统计窗口。正确做法是用比较并交换保证只有一个线程完成跃迁，其余线程发现状态已变则放弃；跃迁成功的那个线程负责重置窗口与发出事件。
时间源的选择也属于正确性问题。所有的窗口计算与等待判定都必须使用单调时钟，绝不能用墙上时钟。墙上时钟会被网络时间同步向前或向后跳变，向后跳一次就可能让一个已经打开了很久的熔断器认为自己"还没到时间"，或者让一个刚打开的熔断器立刻进入半开。这个缺陷平时完全不显现，只在时钟校正的那一刻爆发，排查难度极高。
三、判据设计：怎么定义"失败"
（一）失败的分类：不是所有异常都该计入
1、业务异常与系统异常必须分开
这是熔断器判据设计里的头号原则，也是线上最常见的误熔断根因。
设想一个实名认证接口，当用户提交的身份信息与权威库不一致时，它返回一个"认证不通过"的业务错误。从调用方代码的角度，这可能是一个抛出的异常；从依赖健康度的角度，这是一次完全正常的、被正确处理的调用——服务本身是健康的，它只是给出了一个否定答案。如果这类业务异常被计入失败统计，那么在一个认证通过率本来就只有七成的场景里，熔断器会长期处于打开状态，而下游从未出过任何问题。
同样的问题出现在参数校验失败、余额不足、库存不足、订单状态不允许、权限不足等所有"服务正常工作并给出否定结论"的场景里。判定标准可以概括为一句话：如果重试这次调用、换一个下游实例调用，结果不会改变，那么它就不是依赖的健康问题，不应计入失败。
反过来，连接被拒绝、连接超时、读超时、服务端五百错误、线程池拒绝、序列化失败、依赖返回的明确"系统繁忙"信号，这些都是换个实例或过一会儿再试可能成功的，属于系统异常，应当计入。
工程上有两种表达方式。一种是白名单式的"记录异常"列表：只有列表内的异常类型计入失败。另一种是黑名单式的"忽略异常"列表：除列表外的异常都计入。主流框架通常同时提供两者，忽略列表优先级更高。实践中推荐用忽略列表配合一个自定义的结果判定函数——因为很多依赖并不通过异常表达失败，而是在正常返回的响应体里带一个状态码，这时只有自定义判定函数能拿到正确语义。
2、调用方错误与四百类响应
一个介于两者之间的灰色地带是四百类响应。请求参数格式错误、缺少必填字段、认证令牌过期，这些错误的责任在调用方，重试也不会成功，因此原则上不应计入被调方的健康度。
但有两个例外需要注意。第一个是四百二十九（请求过多）与四百零三中携带配额耗尽语义的响应：它们表达的是被调方的准入控制在起作用，虽然不是系统故障，但持续收到这类响应说明调用方需要主动降速——这时更合适的处理不是熔断，而是触发客户端自适应节流。第二个是四百零一在令牌批量失效场景下的表现：如果调用方的凭证服务出了问题导致所有请求都拿不到有效令牌，这在统计上表现为百分之百的四百零一，此时熔断被调方毫无意义，问题在调用方自己。
结论是：四百类默认不计入失败率统计，但需要单独设置指标与告警；四百二十九这类过载信号走单独的节流通道；调用方自身的凭证或配置问题，靠自身的健康检查发现，而不是靠熔断下游。
3、超时的归属与取消语义
超时是最需要小心的一类。客户端超时既可能是下游真的慢，也可能是调用方自己的线程池排队、垃圾回收停顿或网络出口拥塞造成的。把所有超时无差别计入下游健康度，会在调用方自身出问题时错误地熔断一个健康的下游，从而掩盖真正的问题。
改善方式是区分"排队时间"与"服务时间"。如果客户端能记录请求从提交到真正开始发送的时间，就能把线程池排队造成的耗时排除出去。更进一步，如果链路上传递了截止时间，被调方在开始处理前发现已经超过截止时间可以直接放弃并返回一个明确的"截止时间已过"标识，调用方据此可以判断这次超时的责任方。
主动取消也需要明确语义。当调用方因为超时或熔断放弃了一次调用，它应当尽可能通知下游取消（比如关闭连接、发送取消帧），否则下游会继续为一个无人接收的结果消耗资源。这一点在流式接口与长耗时接口上尤其重要。
（二）慢调用：比错误率更早的信号
1、慢调用率与响应时间阈值
回到第一章的结论：慢比错更危险，而错误率对慢无感。因此一套完整的判据必须包含慢调用维度。
标准做法是引入两个参数：慢调用时长阈值（超过这个耗时的调用被标记为慢调用）与慢调用率阈值（窗口内慢调用占比超过这个比例则熔断）。它与失败率判定是并联关系——任何一个触发都进入打开态。
慢调用阈值怎么定是个实际问题。经验做法是取该接口正常时期响应时间分布的高分位数（比如 P99）再乘以一个系数（比如 2 到 3 倍），得到一个"明显不正常但还不至于超时"的值。它必须显著小于客户端超时时间，否则慢调用信号永远赶不上超时信号，失去了提前预警的意义。一个常见的配置关系是：慢调用阈值约等于超时时间的三分之一到二分之一。
2、平均耗时的陷阱与分位数选择
有些实现（包括早期的一些框架）用"平均响应时间超过阈值"作为熔断条件，这是有问题的。平均值对长尾极不敏感：一百次调用里有五次耗时 10 秒、九十五次耗时 10 毫秒，平均值是 509 毫秒，可能还没到阈值，但那五次已经占用了五十秒的线程时间，且预示着更严重的问题正在发生。反过来，平均值也可能被少数极端值拉爆，造成误判。
因此判据应当用"超过阈值的调用占比"而不是"耗时的平均值"。前者本质上是对分布做了一次二值化，它对长尾敏感、对极端值稳健，且与失败率判定共享同一套比率语义，参数含义统一。
如果确实需要用分位数，应当选择 P95 或 P99，并注意分位数在分布式统计下不可简单平均——多个实例各自的 P99 取平均不等于全局 P99，需要用直方图桶合并后再计算。这是可观测性一节要处理的问题。
（三）统计口径：滑动窗口的两种实现
1、计数窗口与时间窗口
统计窗口有两种主流实现，适用面不同，选错会在特定流量形态下失效。
1.1 计数窗口
计数窗口聚合最近 N 次调用的结果，实现上是一个长度为 N 的环形数组，每次调用结果写入下一个位置，覆盖最老的一条，同时增量维护聚合计数。它的优点是样本量恒定，判定的统计意义稳定；缺点是没有时间概念——一个每小时只被调用十次的接口，配置 N 等于 100 意味着窗口跨越十个小时，十小时前的失败仍在影响当前判定，这显然不合理。因此计数窗口适合高频稳定流量。
1.2 时间窗口
时间窗口聚合最近 T 秒内的调用结果，实现上是一个按秒（或更细粒度）分桶的环形数组，每个桶记录该时间片内的成功数、失败数、慢调用数与总耗时，读取时把仍在窗口内的桶合并。它的优点是时效性明确，"最近十秒的健康度"这个语义符合直觉；缺点是样本量随流量波动，低流量时段样本不足，必须配合最小请求数使用。时间窗口适合流量波动大的场景，也是更通用的默认选择。
1.3 选型建议
如果这条链路的调用频率长期高于每秒数十次，两者都可以，计数窗口略省资源；如果流量有明显的日内波峰波谷、或者存在长时间静默，时间窗口是唯一正确的选择。判断依据不是"哪个更先进"，而是"这条链路的流量形态是否稳定到可以用次数代替时间"。
2、环形数组与桶的实现细节
时间窗口的桶实现有几个必须处理的细节。
桶的复用与清零。环形数组里的桶会被反复复用，写入前必须判断该桶所属的时间片是否已经过期：如果当前时间落在的时间片与桶记录的时间片不一致，说明这是一个过期桶，必须先清零再写入。判断与清零之间存在竞态，需要用桶级别的锁或原子操作保护——这里用整桶的比较并交换（把桶做成不可变对象，整体替换）比逐字段加锁更简洁也更快。
聚合值的维护方式。有两种：一种是每次读取时遍历所有桶求和，另一种是维护一个全局聚合值，写入时增量更新、桶过期时减去旧值。前者读取成本是 O(桶数)，实现简单不易出错；后者读取成本是 O(1)，但过期时的减法与并发写入的加法之间容易出现浮点或计数漂移，长期运行后聚合值可能与真实值偏离。考虑到桶数通常只有几十个，遍历求和的成本可以忽略，推荐前者——用确定性换取一点点性能是划算的。
时间片粒度的选择。粒度越细，窗口边界越平滑，但桶数越多、内存越大。常见配置是窗口十秒、分十个桶，每桶一秒；如果需要更快的响应，可以窗口五秒、分十个桶，每桶五百毫秒。粒度粗到只有一两个桶时，窗口会出现明显的"阶跃"——一个桶过期就丢掉了半个窗口的数据，判定结果会剧烈跳动。
内存占用与实例数量。每个熔断器实例都要维护自己的窗口。如果粒度切到"服务加接口加实例"，实例数会迅速膨胀：五十个下游服务、每个二十个接口、每个二十个实例，就是两万个熔断器，每个几十个桶，内存与垃圾回收压力都不可忽视。这是粒度设计必须考虑的现实约束，也是需要给熔断器实例设置最大数量与闲置回收策略的原因。
3、最小请求数：低流量下的最后一道闸
前面反复提到最小请求数，这里单独说清楚它的定量含义。
最小请求数解决的是小样本下比率不可信的问题。用二项分布做一个粗略估计：假设某接口真实成功率是 99%，窗口内只有 5 次调用，那么观察到 2 次及以上失败的概率约为千分之一——听起来很小，但如果有一千个副本各自独立统计，每个窗口周期就会有大约一个副本误判。窗口每十秒滚动一次，一天下来就是八千多次误熔断。把最小请求数提高到 20，同样条件下观察到 20% 失败率（4 次失败）的概率降到千万分之一量级，误判基本消失。
实用取值建议：最小请求数不低于 20，且不高于窗口内平均调用次数的一半（否则在正常流量下也可能达不到，熔断器等于关闭）。如果某接口的流量低到窗口内平均不足 20 次，说明它不适合用比率型熔断——这类低频接口更适合用"连续失败 N 次"这种确定性判据，或者干脆不做熔断而依赖超时与重试。
4、状态切换时的窗口重置
从打开态回到关闭态时，统计窗口必须重置。原因是打开期间没有真实调用，窗口里残留的是熔断前的失败数据，如果不重置，刚回到关闭态就会因为历史失败数据再次触发熔断，形成"关闭一秒又打开"的抖动。
从关闭到打开时也应重置，避免下一轮统计被污染。半开态需要独立的计数器，与关闭态的窗口分开——半开期间的样本量很小，用关闭态窗口的最小请求数标准去要求它是不合理的。
四、恢复：半开是整个设计里最危险的一段
（一）探测流量的三种放法
1、单请求、固定名额与比例放行
前面在状态跃迁一节里已经列出三种放量方式，这里从风险角度再做一次比较，因为这个选择的后果比它看起来严重。
单请求探测的最大问题不是置信度低，而是它对"部分恢复"无法区分。假设下游有一百个实例，其中三十个已经恢复、七十个还在故障中，单请求探测有三成概率成功。一旦成功，熔断器立刻全量放开，一百万请求涌向一个只有三成健康实例的集群，七成失败，熔断器再次打开——这个来回会反复发生，且每一次都对下游造成一次冲击。
固定名额探测好一些，十个请求里成功三个、失败七个，失败率七成超过阈值，正确地退回打开。但它仍然是"全或无"的：判定通过就是百分之百放开，从零到百分之百的跳变对刚恢复的下游是一次严峻考验，尤其当下游需要重建缓存、重建连接池时，突然的满负荷可能把它再次打垮。
比例放行（渐进放量）是最稳的，也是核心链路上应该采用的方式。它把恢复过程变成一条爬坡曲线，每一档都是一次带有更大样本量的验证，任何一档失败都退回。实现上可以用一个随时间线性或指数增长的放行概率，配合一个令牌桶限制绝对速率上限。
2、自适应节流：把"开关"变成"旋钮"
还有一种思路是把整个二值化的状态机换成连续的概率控制，这是站点可靠性工程实践里客户端自适应节流的做法。
它的核心是在客户端维护两个滑动窗口计数：请求总数与被接受数。当请求总数明显超过接受数乘以一个系数（通常取 1.5 或 2）时，客户端按一定概率主动丢弃请求，丢弃概率大致等于超出部分占请求总数的比例。这个公式的效果是：下游完全健康时丢弃概率为零，完全不干预；下游开始拒绝请求时，客户端按比例自我限速，且限速强度随拒绝率平滑上升；下游恢复时，接受数上升，丢弃概率自动回落——没有状态跃迁，没有半开，没有探测惊群，恢复过程天然平滑。
这种做法的优点是消除了状态机的所有跃迁陷阱，且天然做到"部分放行"，即使在严重过载时也能保持一个稳定的请求—拒绝比。缺点是它不能做到"完全不发起调用"——总有一部分请求会打到下游，因此它保护上游资源的效果不如硬熔断彻底，在下游彻底不可用（连接都建立不了）的场景下不如硬熔断果断。
工程上的最优解往往是两者结合：用自适应节流处理"过载但仍在工作"的场景，用硬熔断处理"完全不可用"的场景，两者的触发条件不同，动作也不同。多个国内主流的微服务框架已经把这套自适应算法作为客户端默认策略，值得作为设计参考。
（二）等待窗口：固定、退避与抖动
1、固定窗口的同步共振
固定等待窗口在单实例下工作良好，在多实例下会制造周期性脉冲。机制在前文已经说明：所有副本几乎同时熔断，于是几乎同时进入半开，探测流量在时间轴上高度聚集，形成尖峰。
这个现象在监控上有一个非常好认的特征：下游的请求量呈现严格周期性的锯齿，周期恰好等于配置的等待时长。看到这个图形，基本可以确定是熔断器的同步共振而不是业务流量的自然波动。
2、指数退避、上限与抖动
修正方案有三层，建议全部采用。
指数退避：每次探测失败后，等待时长翻倍。这样在下游长时间不可用时，探测频率自动降低，避免持续骚扰；同时在下游快速恢复时，第一次探测的延迟仍然很短，不影响恢复速度。
设置上限：退避必须封顶，否则一次长时间故障之后，等待时长会涨到几十分钟甚至更久，下游早已恢复而调用方还在等待。上限值应当参考业务可接受的最长不可用时间，常见取值在 30 秒到 2 分钟之间。
叠加抖动：在最终等待时长上乘以一个随机因子（例如均匀分布在 0.5 到 1.5 之间，或者用"等待时长的一半加上零到一半之间的随机值"这种全抖动形式）。抖动的作用是把副本之间的探测时刻打散，是消除共振最直接有效的手段，实现成本几乎为零，却经常被遗漏。
需要注意抖动的随机源。如果所有副本使用相同的随机种子（比如某些容器环境里进程启动时间与种子相关），抖动会失效。使用进程内的安全随机源或把实例标识混入种子可以避免这个问题。
（三）恢复判定与二次熔断
1、探测样本量与判定标准
半开态的判定标准不应当直接复用关闭态的阈值。原因是样本量不同：关闭态窗口可能有几千个样本，半开态只有十个。用同一个失败率阈值，在十个样本上的判定方差远大于几千个样本。
务实的做法是给半开态设置独立的、更严格的标准。比如关闭态用"失败率超过 50% 则熔断"，半开态可以用"十个探测请求中失败超过 2 个（20%）则退回打开"。更严格的判定牺牲了一点恢复速度，换来的是显著降低"刚恢复又被打垮"的概率——在这个位置上，保守是正确的偏好。
另一个细节是半开态对慢调用的处理。恢复初期的下游往往是"能返回但比较慢"（缓存冷、连接池空、即时编译未热），如果半开态用与关闭态相同的慢调用阈值，很可能刚恢复就被慢调用判据打回去，导致依赖永远无法退出熔断。合理的做法是在半开态适当放宽慢调用阈值，或者在恢复后的一小段时间内不启用慢调用判据。
2、翻转抑制与冷却期
熔断器在"临界健康度"附近会出现频繁翻转：失败率在阈值上下反复穿越，状态在关闭与打开之间高速切换。每次切换都伴随窗口重置、事件发送、日志输出，不仅噪声大，还可能因为窗口反复重置而使判定完全失去意义。
抑制手段有三种，可以叠加。第一种是分离开关阈值（迟滞）：打开的阈值是 50%，关闭的阈值是 20%，中间的区间不触发任何跃迁。这是控制工程里的标准做法，用一个死区消除临界振荡。第二种是最短驻留时间：无论统计如何变化，状态在任一态至少停留 N 秒才允许再次跃迁。第三种是冷却期：从半开成功回到关闭之后的一段时间内，用更敏感的阈值（比如失败率超过 30% 就重新打开），因为刚恢复的依赖二次故障的概率更高，这段时间值得更谨慎地盯着。
3、主动健康探测与被动统计的配合
到目前为止讨论的都是被动统计：用真实业务流量的结果来判断健康度。它的问题是打开态下没有流量，只能靠周期性放探测流量来发现恢复，而探测流量本身带有风险。
补充手段是主动健康探测：熔断器打开期间，用一个专门的、轻量的健康检查接口去探测下游，探测成功后再放业务流量。这个方案的好处是探测不带业务副作用（不会写库、不会扣款），失败也不影响用户；坏处是健康检查接口的结果与业务接口的真实可用性可能不一致——一个只返回"ok"的健康检查接口，在数据库已经不可用时仍然可能返回成功。
因此主动探测的健康检查接口必须做到"有代表性"：它应当真实地触碰关键依赖（比如做一次轻量查询而非仅返回常量），但又不能太重以至于成为新的负担。设计得当的话，主动探测加被动统计的组合是最好的：主动探测负责发现恢复，被动统计负责发现故障，两者各司其职，且都不会对下游造成额外冲击。
五、粒度与位置：熔断器挂在哪一层
（一）四种粒度的取舍
1、服务级、接口级、实例级与参数级
粒度是这道题里区分层次的一个关键点，因为它直接决定了熔断动作的语义是否正确。
服务级熔断以整个下游服务为单位。优点是实现简单、样本量充足、内存开销小；缺点是牵连无辜——下游有二十个接口，其中一个查询接口因为慢查询而劣化，服务级熔断会把另外十九个健康接口一起断掉。这个粒度只适合下游服务功能高度内聚、故障通常整体发生的情况。
接口级熔断以"服务加方法"为单位，是最常用的默认粒度。它把故障隔离到具体接口，避免牵连；样本量通常仍然充足；实例数量可控。绝大多数场景应当选这一档。
实例级熔断以"服务加实例地址"为单位，它对应的其实是异常点检测与实例摘除，语义是"换一台继续调"而不是"不调了"。它能处理"个别实例异常"这类最常见的故障形态——一台机器磁盘满了、一台机器垃圾回收异常、一台机器被调度到了有问题的宿主机上。实例级摘除必须配一个最大摘除比例（比如最多摘除 50%），否则在全体实例都轻微异常时会把所有实例都摘掉，流量无处可去，反而制造完全不可用。
参数级熔断以"接口加某个业务维度"为单位，比如按商户号、按分库分片、按租户。它能处理"下游只有某个分片有问题"的场景，粒度最细、隔离最精准；但实例数量会随维度基数爆炸，内存与管理成本极高，且低基数维度上样本量不足。它只应当用在维度基数有限（几十到几百）且确实存在分片级故障模式的场景，并且必须配合实例数上限与闲置回收。
2、粒度过粗与过细各自的失效方式
粒度过粗的失效方式是"牵连"：一个接口的问题导致整个服务被断，业务面损失被人为放大。它还会掩盖问题——监控上只看到"服务 X 被熔断"，看不出到底是哪个接口的问题，排查效率低。
粒度过细的失效方式是"失灵"：每个熔断器分到的样本太少，长期达不到最小请求数，判定条件永远不满足，熔断器实际上处于关闭状态但没有人知道。这是一种沉默的失效，比误熔断更危险，因为它只在真正需要熔断的时候才暴露。
判断粒度是否合适有一个简单的经验方法：估算该粒度下单个熔断器在一个统计窗口内的平均调用次数，如果显著低于最小请求数，说明粒度太细了，应当向上合并一档。
（二）客户端、服务端与网格：三处部署位置
1、客户端熔断
熔断器的经典位置在客户端（调用方进程内）。它的优势不可替代：请求根本不出本地进程，网络、连接、序列化的开销全部省掉，失败延迟是微秒级；同时它能看到调用方视角的完整信息，包括本地排队时间、线程池状态。
它的局限是每个调用方独立统计，视角不一致（下一节展开），以及多语言环境下需要为每种语言维护一套实现。后者是很多组织最终转向服务网格的直接原因。
2、服务端自保护
服务端也需要自己的保护机制，但它通常不叫熔断而叫过载保护：基于队列长度、CPU 使用率、请求排队时间等信号，主动拒绝一部分请求，把自己的响应时间维持在可接受范围内。
这里的关键设计有两点。一是拒绝要比处理便宜得多，否则拒绝本身会消耗掉服务的全部资源——站点可靠性工程实践里明确指出，在极端过载时后端可能把 CPU 全部花在拒绝请求上，这也是为什么客户端节流是必要的补充。二是拒绝应当区分优先级：把关键请求（比如支付确认）保住，先丢弃可降级请求（比如推荐位刷新），这需要请求上携带优先级标识并在链路上传递。
服务端拒绝时应当返回一个明确的、可被客户端识别的过载信号（比如四百二十九加上重试间隔提示），让客户端能据此调整节流强度，而不是简单返回五百让客户端误以为是系统故障并触发重试。
3、服务网格与代理层
在服务网格架构下，熔断能力下沉到与应用同机部署的代理进程里。这带来三个好处：策略与业务代码解耦，配置可以集中下发；语言无关，任何语言写的服务都自动获得同样的能力；策略变更不需要重新发布业务应用。
代价也很实在：代理层看不到应用内部的语义，它只能基于连接层与协议层的信号（连接失败、五百响应、响应时间）判断，无法区分业务异常与系统异常——而这恰恰是判据设计里的头号原则。因此代理层的熔断只能作为兜底，应用层仍然需要自己的判据。此外代理层引入了额外的网络跳数与延迟，以及一套需要独立运维的控制面。
代理层通常提供两类能力：一类是连接池限额（最大连接数、最大待处理请求数、每连接最大请求数），超出即拒绝，这本质是隔离舱而非熔断；另一类是异常点检测，按连续错误数或错误率把异常实例临时移出负载均衡池，这是实例级熔断。理解这个区分很重要——很多团队以为配了网格的"熔断"就有了熔断能力，实际上配的是连接池限额，对慢依赖完全无效。
（三）分布式状态：本地统计还是全局统计
1、本地统计的偏差与它的优点
主流实现全部采用本地统计：每个调用方进程独立维护自己的窗口，独立判定。这带来一个必然结果：不同副本对同一个下游的健康度判断可能不一致。
不一致的来源有三个。一是流量分布不均，某些副本恰好把请求路由到了故障实例上，另一些副本没有。二是样本量差异，低流量副本可能长期达不到最小请求数。三是时间窗口的相位差，不同副本的窗口边界不对齐。
结果是集群整体呈现"半熔断"状态：三成副本熔断了、七成没有。这在监控上看起来很混乱，但实际上未必是坏事——它天然实现了一种渐进的、部分的保护，比全体一起熔断再全体一起恢复要平滑得多。真正的问题是可解释性差：值班人员看到"有的机器报熔断有的不报"会困惑，需要监控层面做好聚合展示。
本地统计的优点是显而易见的：零额外依赖、零额外延迟、故障期间不需要访问任何外部组件。最后一点尤其重要——熔断器是故障时才发挥作用的组件，它绝不能依赖任何在故障期间可能一起挂掉的东西。
2、全局统计的诱惑与代价
有团队会尝试把统计数据放到共享存储（比如集中式缓存）里做全局聚合，理由是判定更准、行为更一致。
这个方向要慎重。首先，它给每次调用增加了一次远程读写，在正常时期是纯粹的性能损耗。其次，它引入了一个新的依赖，而这个依赖在大规模故障时同样可能过载——熔断器依赖的组件挂掉，熔断器本身就失效了，这是最不能接受的失败模式。第三，全局一致的判定意味着全体副本同时熔断、同时恢复，共振问题被放大到极致。
如果确实需要跨副本的信息共享，更安全的做法是异步、单向、尽力而为：各副本把本地统计异步上报到监控系统，由控制面做聚合分析并在必要时下发"建议熔断"的配置；但本地判定逻辑不依赖这条链路，它挂了熔断器仍然按本地统计正常工作。这样既获得了全局视角，又没有把可用性押在共享组件上。
六、与其他治理手段的协同
（一）熔断与重试：最容易互相拆台的一对
1、重试放大与重试预算
第一章算过重试的放大倍数：每层两次重试、三层链路，放大九倍。这个数字在故障期间是致命的。
第一条纪律是重试只能在一层做，通常是最外层（面向用户的入口）或者最贴近故障的那一层，绝不能层层都做。如果框架默认开启了重试，必须显式检查并在中间层关掉。
第二条纪律是引入重试预算：限制重试请求占正常请求的比例（比如不超过 10%）。实现方式通常是令牌桶——成功的请求给桶里加令牌，失败的请求消耗令牌，桶空了就不再重试。这样在下游大面积失败时，重试会自动停止，而在偶发失败时重试仍然可用。远程过程调用框架的标准重试策略里已经包含这一机制，它比单纯的"最多重试 N 次"要安全得多。
第三条纪律是重试必须带退避与抖动。立即重试是最糟的选择：故障往往需要时间恢复，立即重试几乎必然再次失败，且把三次请求压缩在几毫秒内发出，瞬时压力比正常时还高。
第四条纪律是只重试幂等操作，或者为非幂等操作提供幂等键。这一点属于常识，但在实践中经常被"框架默认开启了重试"这种情况绕过——写接口被自动重试导致重复扣款，是重试机制最典型的事故形态。
2、顺序问题：熔断在重试之内还是之外
这是个容易被忽略却影响很大的实现细节。
如果熔断在重试之内（每次重试都过一遍熔断器判断），那么在熔断打开时，重试会立刻被拒绝，不会产生额外流量；同时每次被熔断拒绝的调用是否计入失败统计需要明确——正确答案是不计入，本地拒绝不是依赖的健康信号。
如果熔断在重试之外（先重试完再由熔断器统计最终结果），那么熔断打开时整个重试链路都不执行，效果类似；但在熔断关闭时，一次逻辑调用产生的多次物理调用只被记为一次结果，统计粒度变粗，熔断器对故障的感知会迟钝。
推荐的组合是：熔断器包在重试之外做最终结果统计，同时在重试循环内部检查熔断状态以便及时中断——即"外层统计、内层短路"。这样既保持了统计的业务语义，又不会在熔断已经打开时还傻傻地重试。
（二）熔断与超时：预算切分
1、没有超时就没有熔断
一个很直接的推论：如果调用没有超时，或者超时时间长到接近无穷，那么慢依赖永远不会产生"失败"结果，熔断器的失败率判据永远不触发，慢调用判据如果没配也就完全失灵。这时熔断器等于不存在，而线程会被一个接一个地吃掉。
因此超时是熔断的前提。每一个跨进程调用都必须有明确的、有限的超时时间，这一条没有例外。默认超时（很多客户端库的默认值是无限或者几分钟）必须被显式覆盖。
2、超时预算的逐层切分与截止时间传递
正确的做法是从用户可接受的端到端时间出发，自顶向下切分预算。举例：用户可接受 800 毫秒，入口层预留 100 毫秒给自身处理与网络，留给下游 700 毫秒；下游服务自身逻辑占 200 毫秒，留给它的三个依赖共 500 毫秒；如果三个依赖是串行的，各分 150 毫秒左右并留出余量；如果是并行的，各自可以用满 500 毫秒但要考虑并发资源。
切分之后要把结果作为截止时间沿调用链传递（通过请求头或调用上下文），每一层在开始处理前先检查剩余时间：如果剩余时间已经不足以完成本层工作，直接放弃并返回，不要发起注定无意义的下游调用。这一条能在故障期间省下大量被浪费的资源。
超时、慢调用阈值与熔断参数之间应当保持一致的量级关系：慢调用阈值小于超时时间，等待窗口大于依赖的典型恢复时间，统计窗口长度大于最小请求数除以峰值每秒调用数。这些关系在参数标定一节会进一步展开。
（三）熔断与降级：断开之后返回什么
1、四类兜底策略及其风险
熔断打开之后，调用方必须返回点什么。选择大致有四类，风险递增。
1.1 静态默认值或空集合
适合展示类、非关键的补充信息，比如推荐位、猜你喜欢、运营标签。风险最低，但要确认调用方能正确处理空值——很多线上事故是"下游降级返回空列表，上游没做空判断直接空指针"。这类兜底还要注意与业务语义的区分：空列表究竟表示"确实没有数据"还是"服务不可用"，两者对上游的含义完全不同，最好在返回结构里用一个显式标记区分。
1.2 缓存的历史数据
返回缓存快照，并明确标注数据的时点与来源。适合对时效性要求不高的展示场景。风险在于陈旧数据可能被误用于决策——所以返回结构里必须带上"这是缓存数据"和"数据时间"，让调用方自己判断能不能用。缓存的有效期应当独立于熔断的等待时长单独设置，否则一次长时间故障会让用户看到几个小时前的数据而毫不知情。
1.3 切换到备用链路
比如切到另一个供应商、另一个机房、另一套实现。适合有真实冗余的场景。风险在于备用链路平时没有流量，可能早已损坏；也在于故障期间全部流量涌向备用链路会把它压垮。必须定期演练备用链路，并给它配置独立的容量与熔断——一个没有自己熔断器的备用链路，会在被主链路流量冲垮之后把故障扩大一倍。
1.4 显式失败
把错误如实返回给上游或用户。这在很多场景下是唯一正确的选择——尤其是涉及资金动作、权限判定、风控决策、库存扣减这些"错了会造成实质损失"的场景。宁可告诉用户"暂时无法处理，请稍后再试"，也不能因为读不到风控结论就默认放行。显式失败需要配套的错误语义：告诉上游这是"暂时不可用、可以稍后重试"，而不是"请求本身有问题、重试也没用"，两者对上游的处理逻辑影响完全不同。
2、兜底本身的可靠性
一条经常被忽略的纪律：兜底路径不能引入新的依赖，也不能比主路径更脆弱。
常见的反模式是"主库查不到就查从库"——但主库故障往往伴随从库故障；"服务调不通就查缓存"——但缓存可能正是压垮服务的那个已经失效的组件；"下游不可用就写消息队列异步补偿"——但消息队列在同一次机房故障里同样不可用。
兜底路径的可靠性必须独立于主路径，且必须被定期验证。一个未经演练的降级方案，在故障时的表现是不可预测的，很多时候它自己就是二次故障的源头。此外，兜底逻辑本身必须极简：它执行在系统最脆弱的时刻，任何复杂逻辑都是风险。
3、什么时候不应该降级
有一类观点值得认真对待：在分布式系统里，兜底本身就是危险的，因为它在你最不了解系统状态的时刻执行一段最少被测试的代码。
所以决策树应当以"这次调用的结果是否会引发不可逆动作"为首要分叉。如果会（扣款、发货、放款、授权），失败时必须显式失败，绝不能用默认值继续；如果不会（展示、统计、日志、推荐），才考虑兜底。这条规则简单到可以写进代码评审清单，但它能挡住绝大多数由降级引发的资损事故。
（四）熔断与隔离舱、限流、负载均衡
1、隔离舱限定爆炸半径
隔离舱的核心动作是给每个下游依赖分配独立的资源配额（线程池或信号量），确保一个依赖占满自己的配额后不会影响其他依赖。
线程池隔离与信号量隔离各有取舍。线程池隔离能真正实现超时中断（调用线程与业务线程分离，超时后可以放弃等待），但每个依赖一个线程池带来上下文切换开销与线程数膨胀，且丢失了线程本地变量的传递（需要显式传播上下文）。信号量隔离开销极小，但无法中断已经开始的调用——它只能限制并发数，不能限制单次调用的时长，因此必须配合客户端超时使用。
实践建议：默认用信号量隔离配合严格超时，只在依赖的超时不可控（比如某些不支持超时的第三方客户端库）时才用线程池隔离。
2、自适应限流与熔断的分工
自适应限流（基于系统负载动态调整准入速率）与熔断解决的是不同方向的问题，但两者的信号有重叠，容易配置冲突。
清晰的分工是：限流在被调方，依据自身负载信号（CPU、队列长度、排队时间），动作是拒绝超额请求；熔断在调用方，依据依赖的健康信号，动作是不发起调用。两者串联工作时，被调方的限流拒绝会作为失败信号进入调用方的统计——这时要注意，把限流拒绝直接计入熔断失败率，会导致"被限流就被熔断"，而限流恰恰说明服务还活着只是忙。更合理的处理是把过载信号引导到客户端节流通道（降低发送速率）而不是熔断通道（完全停止发送）。
3、异常点检测与负载均衡的配合
前面说过，实例级异常摘除的语义是"换一台"。它与负载均衡策略需要协同：摘除之后，被摘实例的流量会重分布到剩余实例上，如果剩余实例已经接近满载，这次重分布可能直接把它们压垮，形成"摘一台垮一台"的连锁摘除。
防护手段有两条：一是设置最大摘除比例，保证任何时候都有足够比例的实例在池中；二是摘除时配合"恐慌阈值"——当健康实例比例低于某个值（比如 50%）时，负载均衡放弃健康检查结果，把流量均匀分给所有实例，因为此时区分健康与否已经没有意义，均摊反而是更好的策略。
七、参数怎么定：从拍脑袋到有据可依
（一）参数集与它们之间的耦合
1、核心参数清单
一套完整的熔断器配置至少包含以下参数，它们不是彼此独立的旋钮。
统计窗口类型与长度：决定健康度的时间视野。时间窗口推荐 10 到 60 秒，计数窗口推荐 100 以上。
最小请求数：低流量保护闸，推荐不低于 20。
失败率阈值：推荐 50%，核心链路可下调到 30%，弱依赖可上调到 70%。
慢调用时长阈值与慢调用率阈值：前者取正常 P99 的 2 到 3 倍且明显小于超时时间，后者与失败率阈值同量级。
打开态等待时长（及退避上限、抖动系数）：初始值应大于依赖的典型恢复时间，常见 5 到 30 秒，退避封顶 60 秒左右。
半开允许请求数与半开判定阈值：前者推荐 5 到 10，后者比关闭态阈值更严格。
关闭阈值（迟滞下界）与最短驻留时间：用于抑制翻转。
调用超时时间：虽然通常不算熔断器参数，但它是整套配置的基准，必须一起确定。
2、参数之间的相互约束
参数之间存在硬性约束，违反了配置就是自相矛盾的：
统计窗口长度乘以峰值每秒调用数必须显著大于最小请求数，否则窗口内永远凑不满样本，熔断器等于关闭。
慢调用阈值必须小于超时时间，否则慢调用永远先变成超时，慢调用判据失去提前预警的意义。
半开允许请求数不应大于最小请求数，否则半开阶段的样本量比关闭阶段还大，探测冲击过强。
等待时长应当大于依赖重启或扩容所需的典型时间，否则每次探测都必然失败，只是在无效地骚扰。
迟滞下界必须小于打开阈值，且两者之间要留出足够宽的死区（建议至少 20 个百分点）。
（二）用数据定阈值的三种方法
1、从基线分布反推
最可靠的方法是用历史监控数据倒推。取该接口过去一到四周的响应时间分布与错误率分布，计算稳态时期的 P50、P95、P99 与错误率的分布特征。
慢调用阈值取稳态 P99 的 2 到 3 倍：这个值意味着"比最坏的正常情况还要差好几倍"，落在这个区间的调用几乎可以确定不正常。
失败率阈值取稳态错误率加上若干倍标准差，并向上取整到一个整数百分比。如果稳态错误率是 0.5%、标准差 0.3%，那么 5% 已经是极显著的异常，没必要非用 50%——阈值应当由数据决定而不是由默认值决定。对于稳态错误率本来就有几个百分点的接口（比如依赖外部渠道的支付通道），阈值自然要高得多。
2、压测与故障注入标定
基线分布告诉你"正常长什么样"，压测告诉你"崩溃前长什么样"。
具体做法是在预发环境对下游施加逐步增加的压力，记录响应时间与错误率随负载变化的曲线，找到拐点——即响应时间开始非线性上升的那个负载点。熔断阈值应当设在拐点之前，让熔断在系统进入不可逆恶化之前生效。
同时做故障注入实验：注入固定比例的失败与固定时长的延迟，验证熔断器是否在预期时间内打开、是否在故障移除后的预期时间内恢复、恢复过程是否平滑。这个实验的产出不只是参数，还包括"从故障发生到熔断打开需要多久"这个关键指标——如果这个时间超过几秒，说明窗口太长或最小请求数太高，需要调整。
3、按流量档位分级配置
同一个接口在不同时段的流量可能相差一个数量级。一套固定参数无法同时适应大促峰值与凌晨低谷。
处理方式有两种。简单的是按流量档位准备几套参数（高峰、平峰、低谷），由配置中心根据实时流量切换。复杂但更优雅的是让最小请求数与窗口长度自适应：比如最小请求数取"窗口内平均调用数的 20% 与固定下限 20 之中的较大值"，这样它会随流量自动伸缩。
无论哪种方式，都要避免一个陷阱：参数切换本身不能成为抖动源。切换时应当重置统计窗口并给一个短暂的静默期，否则新旧参数交界处的判定会很奇怪。
（三）配置治理
1、动态下发与灰度
熔断参数必须能在不发布应用的前提下修改，这是故障处置的基本要求。配置中心下发是标准做法，但要注意三点：配置变更要有生效确认（能看到有多少实例已经应用了新配置）；配置结构要有版本号与校验（防止下发一个格式错误的配置把所有实例的熔断器打挂）；配置读取失败时要有明确的降级行为（用上一次的有效配置，而不是用空配置或默认配置）。
灰度是必需的。熔断参数的错误配置影响面极大——把失败率阈值从 50% 误配成 5%，会瞬间熔断所有依赖。因此参数变更应当先在少量实例上生效，观察一段时间的熔断触发次数与拒绝量，确认无异常后再全量。
2、审计、回滚与默认值
每一次参数变更都应当记录变更人、变更时间、变更前后的值与变更原因。故障复盘时，"这个参数是什么时候被改成这样的"是高频问题。
回滚必须是一键的，且回滚路径不能依赖任何可能同时故障的组件。一个务实的做法是在应用本地保留最后一次已知良好的配置快照，配置中心不可用时用它兜底。
默认值的选择原则是保守。熔断器的默认配置应当倾向于"不轻易熔断"：较高的最小请求数、较高的失败率阈值、较短的打开时长。理由是误熔断造成的可用性损失是立刻可见的业务损失，而漏熔断造成的损失只在真实故障时才发生，且还有超时、隔离舱、限流等其他机制兜底。让每个接入方主动收紧参数，比让他们在被误熔断之后紧急放宽要好。
八、可观测性：熔断器必须能自证
（一）必须暴露的指标
1、指标清单
熔断器是一个会主动改变系统行为的组件，它必须能解释自己的每一个决策。至少需要暴露以下指标。
状态指标：当前状态（关闭、打开、半开、强制态）的枚举值或状态时长。这是排查时第一个要看的东西。
跃迁计数：各个方向跃迁的累计次数。频繁跃迁说明参数在临界区，需要调整迟滞。
拒绝量：因熔断而被本地拒绝的请求数。这是熔断器造成的直接业务影响，必须与真实失败量分开统计——把两者混在一起是很多监控体系的通病，会让人误以为下游还在大量失败，而实际上下游可能早已恢复。
窗口内统计：当前窗口的调用总数、失败数、慢调用数、失败率、慢调用率。这些是判定的直接输入，暴露出来才能解释"为什么熔断了"。
半开态指标：半开次数、半开成功次数、半开失败次数。半开成功率长期偏低说明等待时长设得太短。
2、维度与基数控制
指标的维度通常包括调用方服务、被调方服务、接口方法。如果做了实例级或参数级熔断，实例地址与业务维度也会成为标签——这时基数会迅速膨胀，可能把监控系统打垮。
控制手段有三条：实例级指标只上报聚合值（比如"当前被摘除的实例数"）而不是每个实例一条时间序列；高基数业务维度做白名单，只对少数重点维度上报明细；对指标做本地预聚合，按固定周期批量上报而不是每次调用都上报。
（二）事件、日志与告警
1、状态跃迁事件
每一次状态跃迁都应当产生一条结构化事件，字段至少包括：熔断器标识（服务加接口）、跃迁前状态、跃迁后状态、跃迁时刻、触发原因（失败率超阈值、慢调用率超阈值、人工强制）、触发时的窗口统计快照（总数、失败数、失败率、慢调用率）、当前生效的阈值配置、本次打开的预计等待时长。
带上窗口快照与阈值配置这一点很关键：它让事件本身自带解释，值班人员看到一条事件就能判断这次熔断是否合理，不需要再去翻别的系统对照配置。
日志方面要注意抑制：熔断打开期间，每一个被拒绝的请求都打一条日志，会在故障期间产生海量日志，反过来加重系统负担甚至打满磁盘。正确做法是状态跃迁打详细日志，拒绝行为只计数不打日志（或者按固定采样率打）。
2、告警的分层
一个重要的判断：熔断本身不一定值得告警。
熔断打开说明保护机制正常工作，真正的问题是下游为什么故障——那个应该由下游自己的告警发现。如果对每一次熔断都告警，在依赖众多的系统里会产生大量重复告警，掩盖真正的信号。
更合理的告警分层是：下游故障由下游的可用性告警负责；熔断器只对"异常模式"告警，包括长时间处于打开态（超过 N 分钟未恢复，说明故障持续或等待时长配置有问题）、跃迁过于频繁（单位时间跃迁次数超阈值，说明参数在临界区）、熔断拒绝量占总请求比例过高（说明业务影响面大）、半开长期失败（说明依赖迟迟未恢复）。这四类才是熔断器自身需要人介入的情况。
（三）一条十分钟收敛的排查路径
当有人报告"某功能不可用"，而怀疑与熔断有关时，一条固定的排查路径能显著缩短定位时间。
第一步，确认调用方返回的错误类型：是熔断拒绝，还是真实的调用失败。这一步要求熔断拒绝必须有独立的、可识别的错误码或异常类型——如果熔断拒绝伪装成普通的调用失败，这一步就无法进行，整条路径断在起点。
第二步，查看该熔断器的当前状态与最近的跃迁事件。事件里带的窗口快照会直接告诉你是失败率触发还是慢调用触发。
第三步，对照触发时刻的下游监控：下游的错误率与响应时间在那一刻是否真的异常。如果下游一切正常，说明是误熔断，需要检查判据配置（是不是把业务异常计入了）或统计逻辑。
第四步，如果下游确实异常，问题转移到下游，熔断器的工作到此为止；如果下游正常，继续第五步。
第五步，检查调用方自身：线程池是否饱和、垃圾回收是否异常、网络出口是否拥塞。前面说过，调用方自身的问题会表现为下游超时，从而误熔断健康的下游。
第六步，检查配置变更记录：最近是否有人改过阈值。
这条路径能走通的前提，是设计期就把这些字段和指标准备好了。如果熔断拒绝与真实失败混在一起、跃迁事件不带窗口快照、配置变更没有记录，那么这条十分钟的路径会变成几个小时的猜测。
九、测试与演练
（一）单元测试：把时间变成可注入的参数
1、虚拟时钟
熔断器是强时间相关的组件，如果测试里用真实的休眠来等待窗口滚动，一套测试可能要跑几分钟，而且天生不稳定。
正确做法是把时间源抽象成一个接口，生产环境注入单调时钟，测试环境注入可手动推进的虚拟时钟。这样"等待 30 秒后进入半开"这个行为可以在毫秒内被验证，且完全确定。这个设计决策应当在实现之初就做出——事后再改，几乎等于重写。
2、表驱动的状态机测试
状态机的测试应当覆盖所有合法跃迁与所有非法跃迁。用表驱动的方式列出（初始状态、输入事件、期望状态、期望副作用）四元组，逐条验证。
必须覆盖的边界包括：恰好达到最小请求数时的判定、恰好等于阈值时的判定（大于还是大于等于要明确并测试）、窗口边界上的样本归属、半开名额恰好用尽时的行为、半开期间抛出未受检异常时名额是否归还、并发调用下跃迁是否只发生一次。
最后这条需要专门的并发测试：用大量线程同时触发跃迁条件，断言状态跃迁事件恰好发生一次、窗口恰好重置一次。这类缺陷不会被普通的单线程测试发现。
（二）集成测试与故障注入
1、故障注入的四种形态
要验证熔断器在真实环境中的行为，至少需要注入四种故障形态，因为它们触发的是不同的判据路径。
延迟注入：给下游响应加固定或随机延迟，验证慢调用判据。要分别测试"延迟小于超时"（触发慢调用判据）与"延迟大于超时"（触发失败判据）两种情况。
错误注入：让下游按比例返回五百错误，验证失败率判据，并验证业务异常不会触发熔断。
拒绝注入：直接拒绝连接或关闭端口，验证连接失败的处理路径——这条路径与五百错误走的代码分支通常不同。
部分故障注入：只让下游的一部分实例故障，验证实例级摘除是否生效、最大摘除比例是否被遵守、剩余实例是否被压垮。
2、演练脚本与验收标准
演练不能只做"注入故障、观察是否熔断"，必须有明确的量化验收标准：
从故障开始到熔断打开的时间小于预期值（通常要求几秒内）；熔断打开后调用方的线程池占用率回落到正常水平；熔断期间用户侧的错误是预期的降级表现而非超时等待；故障移除后到熔断关闭的时间小于预期值；恢复过程中下游的瞬时流量峰值不超过其容量的某个比例（验证渐进放量有效）；整个过程中没有出现状态卡死。
演练应当定期进行而非只在上线前做一次。依赖会变、参数会被改、代码会重构，一套半年没验证过的熔断配置，其实际行为是未知的。
（三）上线前的自检清单
以下问题应当在设计评审时逐条确认，每一条都对应前文的一个具体陷阱：判据是否区分了业务异常与系统异常；是否配置了慢调用判据；最小请求数是否与实际流量匹配；窗口类型是否适配流量形态；等待时长是否有退避与抖动；半开名额是否会在异常路径上泄漏；是否使用了单调时钟；状态跃迁是否用了原子操作；是否有强制打开与强制关闭的人工开关；熔断拒绝是否有独立的错误标识；跃迁事件是否携带窗口快照；参数是否可动态下发且支持灰度与回滚；兜底路径是否引入了新依赖；涉及资金或不可逆动作的调用是否走了显式失败；是否有故障注入的演练记录。
十、答题范式与失分点
（一）三种时间长度下的作答
1、三分钟版本
如果只有三分钟，说清四件事：熔断器解决的是调用方资源被故障依赖耗尽导致的级联故障；核心是一个基于滑动窗口统计的三态状态机，判据必须同时包含失败率与慢调用率，并用最小请求数防止低流量误判；恢复阶段用半开探测，等待时长需要指数退避加抖动以避免多副本共振；断开之后的兜底策略以"是否引发不可逆动作"为分界，涉及资金的场景必须显式失败。
2、十分钟版本
在三分钟版本基础上补三层。判据层：业务异常不计入、四百类不计入、超时归属要区分调用方与被调方。粒度层：默认接口级，实例级对应异常点摘除且必须设最大摘除比例，参数级要控制基数。协同层：重试只在一层做且要有预算，超时必须逐层切分并传递截止时间，熔断与限流方向相反不可互替。
3、四十分钟版本
按本文的章节顺序完整展开，并主动引入四个能体现深度的话题：滑动窗口的桶实现与聚合值维护方式的取舍；半开名额在异常路径上泄漏导致状态卡死的具体机制与修复；自适应节流作为连续控制对二值状态机的替代及其适用边界；本地统计与全局统计的可用性权衡，以及为什么熔断器绝不能依赖故障期间可能一起挂掉的组件。
（二）十二个高频失分点
第一，只画三态状态图，不谈判据、窗口与参数。第二，把所有异常一律计入失败率，导致业务失败率高的接口被长期误熔断。第三，只看错误率不看响应时间，对最危险的慢依赖故障完全失明。第四，不设最小请求数，低流量接口被随机抖动打成熔断。第五，等待窗口用固定值且无抖动，多副本探测共振形成周期性脉冲。第六，半开名额只减不还，异常路径上状态永久卡死。第七，用墙上时钟做窗口与等待计算，时钟校正时行为异常。第八，状态跃迁用读—判断—写而非原子操作，出现重复跃迁与重复重置。第九，熔断与重试叠加且重试在多层配置，故障期间放大数倍流量。第十，只说"熔断后降级"，说不清降级返回什么、兜底是否可靠、什么场景不该降级。第十一，熔断拒绝与真实失败混在同一个错误码里，故障排查无从下手。第十二，参数靠默认值或拍脑袋，说不出阈值与基线分布、压测拐点之间的关系。
（三）结论
熔断器的价值不在于"能断开"，而在于它在正确的时刻、以正确的粒度、断开正确的时长；它必须对判据足够挑剔，对恢复足够谨慎，对自己的每一次决策足够坦白。一个断得快但断错的熔断器，比没有熔断器更危险——因为它把一次局部故障，变成了一次由保护机制自己制造的全局故障。
参考资料
模式与理论
- Martin Fowler：CircuitBreaker —— 熔断器模式的经典阐述，含状态机与实现要点
- Circuit breaker design pattern（维基百科） —— 模式定义、状态与常见变体
- 微软架构中心：断路器模式 —— 适用场景、注意事项与实现建议
- 微软架构中心：舱壁模式 —— 资源隔离与爆炸半径控制
- AWS 规范性指南：断路器模式 —— 云上落地的结构与状态存储选择
- microservices.io：Circuit Breaker —— 微服务可靠性模式全景中的定位
- 《Release It!》第二版 —— 稳定性模式与反模式的系统论述，熔断器概念的源头之一
站点可靠性工程实践
- Google SRE Book：Handling Overload —— 客户端自适应节流算法与过载时的拒绝成本
- Google SRE Book：Addressing Cascading Failures —— 级联故障的成因、放大机制与处置手段
- Google SRE Workbook：Managing Load —— 负载管理的完整方法论与案例
- AWS Builders' Library：超时、重试与带抖动的退避 —— 超时预算、退避与抖动的定量分析
- AWS Builders' Library：避免分布式系统中的回退 —— 兜底路径为何危险及替代做法
框架实现
- Resilience4j CircuitBreaker 文档 —— 计数窗口与时间窗口、最小请求数、慢调用率、半开名额的完整参数语义
- Resilience4j 源码仓库 —— 环形数组窗口与状态机的参考实现
- Netflix Hystrix：How it Works —— 线程池隔离、信号量隔离与熔断的经典设计
- Netflix Hystrix 项目现状说明 —— 项目进入维护模式的说明与后续选型建议
- Sentinel 熔断降级文档 —— 慢调用比例、异常比例、异常数三类策略与探测恢复
- Sentinel 熔断降级 Wiki —— 规则字段、统计口径与使用注意事项
- Polly 弹性策略库 —— 熔断、重试、超时、隔离舱、兜底策略的组合方式
- Kratos 熔断中间件 —— 客户端熔断中间件与自适应算法的默认实现
- Kratos Aegis 组件 —— 自适应熔断与限流算法的独立实现
- go-zero Circuit Breaker —— 基于自适应节流思路的熔断实现与自动接入
代理与服务网格
- Envoy：Outlier detection —— 连续错误、错误率、驱逐时长与最大驱逐比例的语义
- Envoy：Circuit breaking —— 连接池限额类熔断与它的适用边界
- Istio 熔断任务 —— 目标规则中熔断配置的完整示例
- Istio DestinationRule：OutlierDetection 参考 —— 各字段的精确定义与默认值
重试与流量协同
- gRPC 重试指南 —— 重试策略、退避参数与基于令牌桶的重试节流
- RFC 9110：HTTP 语义 —— 方法幂等性定义与状态码语义，重试安全性的判定依据
- RetryGuard：云原生应用中的重试风暴防治 —— 重试放大机制的量化分析与防护方案
中文实践资料
- 服务降级与熔断详解：Fallback、熔断器状态机与框架选型 —— 状态机、兜底策略与主流框架的对比整理
- 理解熔断器模式：构建弹性系统的关键设计模式 —— 模式原理与工程实现要点
- Hystrix 断路器与滑动窗口实现分析 —— 桶结构与窗口统计的源码级说明
- go-zero 源码阅读：熔断器实现 —— 自适应熔断算法的实现细节与源码走读
- Kratos 熔断中间件源码 —— 客户端熔断中间件的实现路径与默认策略
- Sentinel 深度解析：限流与熔断降级的稳定性保障实践 —— 规则配置、阈值选择与落地经验
