熔断（Circuit Breaker）是一种自动保护机制：当对某个下游服务的调用连续失败到一定次数，系统会主动"跳闸"，在一段时间内直接拒绝新的调用，不再真的发请求；等冷静期过后再试探性地放一点流量过去，成功就恢复，失败就继续跳闸。
这个叫法来自电路里的保险丝。家里的电线短路，保险丝烧断，整屋断电——听起来是坏事，但它避免了电线过热起火。软件里的熔断是同一个逻辑：与其让请求一次次砸向一个已经挂掉的服务，不如干脆停手。
为什么需要它
想象一栋写字楼的电梯坏了。如果没人管，每个到大厅的人都去按一次按钮、等五分钟、再骂一句走开。人越积越多，大厅被堵死，连走楼梯的人都挤不出去。这时候正确做法是：门口立个牌子"电梯故障，请走楼梯"。这就是熔断。
在 AI 应用里，最典型的下游就是模型 API。假设你的产品每次对话要调两次模型接口，高峰期每秒几百次调用。某天模型服务开始大面积超时，会发生三件事：
1. 资源被拖死：每个请求都要挂住几十秒等超时，连接池、线程、内存被迅速占满，本来正常的其他功能也跟着瘫痪。这就是雪崩。
2. 重试火上浇油：很多 SDK 默认会重试。下游已经扛不住了，你还在成倍地加倍请求，等于往伤口上撒盐。
3. 账单失控：如果失败是"半失败"——比如返回了错误但你仍按 token 计费，或者你切到更贵的备用模型，短时间内的调用量可能把预算烧穿。
熔断就是在这三件事发生之前把闸拉下来。
三种状态
| 状态 | 行为 | 怎么进入 |
|---|---|---|
| 关闭（Closed） | 正常放行所有请求，同时统计失败率 | 初始状态、试探成功后 |
| 打开（Open） | 直接拒绝，不发真实请求，立刻返回兜底结果 | 失败率/连续失败数超过阈值 |
| 半开（Half-Open） | 放少量请求试探 | 打开状态持续一段冷却时间后 |
关键在"立刻拒绝"：请求不再等待，用户拿到的要么是缓存答案，要么是一句"服务繁忙，请稍后重试"，响应时间从几十秒变成几十毫秒。
和相邻概念的区别
- 重试（Retry）：重试是"再试一次"，熔断是"别再试了"。两者方向相反，通常配合使用：少量重试 + 熔断兜底。
- 限流（Rate Limiting）：限流按"量"卡，不管下游死活，保护的是自己不被压垮；熔断按"错"卡，看下游是不是已经不行了。
- 降级（Fallback）：熔断是决策，降级是决策之后的动作。跳闸了要给用户什么，那是降级要回答的。
- 超时（Timeout）：超时是单次调用的止损，熔断是跨请求的止损。只有超时没有熔断，等于每次都白等一遍。
对从业者的实际意义
第一，阈值不要拍脑袋。连续失败 5 次就跳闸，还是失败率超过 50% 且样本量足够才跳，取决于你的 QPS。低流量场景用连续次数更灵敏，高流量场景用滑动窗口失败率更稳。
第二，冷却时间要留够。下游重启、扩容、恢复都需要时间。冷却太短会导致"跳闸—试探—又跳闸"的抖动，反而持续给它压力。
第三，多模型架构里，熔断要按供应商分别计数。别让 A 家的故障把 B 家的调用也一起掐了，那就白白浪费了备份方案。
第四，跳闸必须可观测。熔断本身是"静默失败"，如果不打点、不告警，你可能几小时后才发现用户一直在看兜底文案。指标上至少要能看到：当前状态、跳闸次数、被拒绝的请求数。
第五，熔断解决的是"止血"，不是"治病"。它让系统不至于全军覆没，但下游为什么挂，还得靠日志和 trace 去查。
最后提醒一句：各家云厂商和框架对熔断的参数命名、默认值、统计口径都不完全一样，具体配置以官方文档为准，别照搬别人的数字。