熔断降级实战：从静态阈值到自适应熔断

没有熔断的系统，故障是会传染的

微服务链路上，一个下游变慢（如数据库抖动）会让上游线程池被同步等待占满，进而把超慢传导给更上游——线程池打满、连接耗尽、整条链路雪崩。熔断的本质是快速失败：发现下游不健康时，直接拒绝请求而不是傻等；降级的本质是有损服务：拒绝核心链路之外的请求，保住主流程。两者配合，把「全站不可用」压缩成「局部功能降级」。一、熔断三态机：closed / open / half-open

1. closed（正常）：统计窗口内错误率或慢调用比例超过阈值 → 跳闸进入 open；
2. open（熔断）：所有请求快速失败（走降级逻辑），持续一个熔断时长后进入 half-open；
3. half-open（试探）：放行少量探测请求，成功则恢复 closed，失败则重新 open。

关键参数经验值：统计窗口 10 秒、最小请求数 20（低于此不统计，避免低流量误跳）、错误率阈值 50%（错误率高但量小的抖动不熔断）、慢调用阈值 RT 超 P99 的 2 倍、熔断时长从 10 秒起步指数递增。

二、静态阈值的坑：高峰期被误熔断

固定阈值（如错误率 50%）在流量低谷和高峰含义完全不同：低谷期 10 个请求错 5 个就跳闸（可能只是偶发），高峰期真正的慢性劣化反而因为「错误率还没到 50%」迟迟不触发。自适应熔断（如统计滑动窗口的 RT 与成功率动态计算）按当前流量特征动态调整敏感度，是这类问题的解法：流量越大判定越保守，流量越小越容易快速跳闸。

三、降级预案：提前写好「不干什么」

降级不是随便返回一个错误页，而是业务预先定义的有损模式：

1. 读降级：推荐列表走默认排序、详情页非关键字段（评价数、库存提示）隐藏、静态兜底数据；
2. 写降级：非核心写入（收藏、浏览记录）转异步队列延后处理，核心写入（下单、支付）绝不降级而是熔断快速失败；
3. 功能开关：降级开关要支持一键切换且全链路生效（配置中心推送），演练时验证开关的生效时间——配置推送 5 分钟才生效的开关在故障时形同虚设。

四、与限流、隔离的关系

熔断是「被动止损」，限流是「主动防御」，线程池/信号量隔离是「爆炸半径控制」：不同下游用不同线程池，一个下游打满不拖累其他调用。三者是一套组合拳——隔离决定故障能波及多大，熔断决定故障持续多久，降级决定故障期间用户看到什么。

五、验收标准

上线前必须演练：手动把下游 RT 拉高，验证熔断在预期时间内跳闸、降级文案正确、half-open 恢复顺畅；再把下游恢复，验证系统自动回位。熔断参数不是一次调好的——每次大促后复盘跳闸记录，按真实数据校准阈值。

熔断降级的成熟度标志：故障发生时，用户只是「功能少了一点」，而不是「页面白屏了」。这中间的差距，就是预案的深度。