限流上线之后：熔断与降级的决策链设计

网关系列的第三篇。前两篇聊了限流（守住容量）和监控指标（看清状态），这篇聊故障传播链上的最后两道闸：熔断和降级。很多团队把这两个词混着用，实际上它们回答的是两个不同的问题——熔断管「要不要暂停调用」，降级管「暂停之后用户看什么」。

为什么限流不够

限流保护的是被调用方的容量，但它有个盲区：当下游已经病了（错误率飙升、响应拖长），限流器还在把请求匀速送过去。每个请求都等满超时才死，上游的线程池被拖垮——这就是级联故障的经典路径。熔断解决的正是这个盲区：快速失败，替慢死。

熔断的决策链：三态与触发条件

熔断器经典三态：闭合（正常放行）→ 打开（直接拒绝）→ 半开（放探测流量）。设计的关键不在状态机，在触发条件的口径：

1. 错误率窗口：滑动窗口内错误率超阈值（如 50%）。注意最小样本数——10 个请求里错 6 个就熔断，会把低流量服务熔得莫名其妙。
2. 慢调用比例：错误率没超但响应时间劣化（如 P95 超阈值 3 倍的请求占 60%）——慢故障比快故障更常见，只盯错误率会漏掉。
3. 半开探测的节奏：打开后每 30 秒放 5 个探测请求，全对则闭合，任一错则重置计时。探测流量要打到真实链路（带真实业务标签），否则探测成功不代表恢复。

降级的决策链：预案分级

熔断触发后用户看什么，需要预案提前分级，而不是现场想：

• 一级降级（读缓存）：核心数据展示最近一份缓存，页面标注数据更新时间。成本最低，适用大多数读场景。
• 二级降级（功能收起）：非核心模块整体隐藏——推荐位、评论区先撤，保主流程。
• 三级降级（静态兜底）：只剩维护提示和预计恢复时间。丑，但诚实。

分级的判断标准只有一条：这个功能挂了，用户的主流程还通不通。主流程通的降级是体验损失，主流程不通的是事故。

决策链串起来

完整的防线是四级递进：限流挡超额流量 → 熔断挡病态下游 → 降级保用户体验 → 监控验证每一步是否生效。这四级的配置要放在同一处管理（网关或配置中心），因为它们的参数互相关联——熔断阈值调松，限流的压力口径就要跟着看。

上线之后必做的一件事：故障演练。拿预发环境手动把下游错误率打上去，看熔断是否如期打开、降级是否如预案生效。没演练过的预案，等于没有预案。

（网关系列：限流实践 → 可观测三指标 → 本文：熔断降级 → 下一篇：网关的配置治理）