熔断：别被名字骗了，它的核心根本不是断

听到“熔断”这词，你脑子里蹦出的是什么？保险丝？电路过载自动跳闸？错得离谱。在分布式系统里，熔断其实是个统计判决器——它根本不关心电路，只关心概率。

我第一次在线上压把熔断阈值调到 50% 的时候，整个集群秒级雪崩。后来才想通：这玩意儿的灵魂是滑动窗口和半开试探，而不是那个粗暴的开关。

状态机是个圈，但大多数人只看到两条边

教科书上永远画着 CLOSED → OPEN → HALF_OPEN → CLOSED 的环。好像很干净。对吧？但现实是——你根本不知道什么时候该从 OPEN 切到 HALF_OPEN。Hystrix 默认是 5 秒后自动转，Resilience4j 可以配个 waitDuration。但这里有个坑：时间窗口和请求量分布强相关。假设你设置了熔断后 10 秒才允许半开，结果那段时间正好流量低谷，半开的第一个请求失败了……就又直接打回 OPEN。然后就死循环了。我见过一个支付网关就因为这种死循环，故障恢复时间从预估的 30 秒拖成了 47 分钟。

说白了，熔断器就是一个有限状态机，但它的转移条件依赖统计指标。而这些指标怎么算？滑动窗口。

滑动窗口——把时间切成片，每一片都是血

你得把时间轴切成 N 个桶（bucket）。比如 10 秒窗口，10 个桶，每个桶宽 1 秒。请求进来，先找到当前时间对应的桶，然后把结果（成功/失败）扔进去。统计的时候，把窗口内所有桶的合计失败率算出来，超过阈值就熔断。

但问题来了——并发写桶怎么办？ 早期 Hystrix 用累加器，每次请求都加锁更新总计数，写竞争严重。后来改成每个桶独立累加，窗口移动时只调整头尾。但 Java 里的 LongAdder 虽然分散了热点，依然有伪共享。Netflix 那帮人后来在 Hystrix 里直接用了一种环形缓冲区，基于数组下标取模，每个槽位用 AtomicLong 无锁更新。看看这个对比数据：

看 P99 延迟的差距——慢的能到 340 毫秒，快的只有 12 毫秒。这就是工程美学：用数组和原子操作避免锁，把统计开销压到几乎不可见。

熔断真不是越灵敏越好，慢调用比失败更致命

很多人只看失败率。可超时不算失败吗？ 算，但传统熔断器把超时归类为失败之前，已经晚了。一个下游接口从 50ms 胀到 3s，你的熔断器还傻傻等着失败计数呢，调用方线程池早就满了。

所以 Resilience4j 搞了慢调用熔断。它把大于某个阈值（比如 300ms）的请求单独统计比例。我压测过一个电商详情页，依赖库存服务。库存服务偶尔 GC 停顿导致 P99 升高，传统失败率熔断完全无视——失败率还是 0。但慢调用比例能从 2% 飙到 60%，这时候熔断器触发，全部降级为缓存数据。结果呢？用户体验抖动从 5 秒缩短到 200 毫秒。没有慢调用熔断，你甚至意识不到系统正在腐烂。

下面说三个落地的坑，每个都流过血。

坑一：半开状态的请求量风暴

半开的时候，系统只允许少量请求通过（比如配置 permitMinimum=3）。但如果微服务有几十个节点，加起来同时半开？瞬间就打爆下游。我有一次跟同事在凌晨 2 点追这个现象——下游一恢复，上游所有实例同一秒放量，下游立刻又被打挂，然后全部又熔断。我们后来搞了个集群熔断，共享一个全局的熔断状态，但那样又引入了分布式一致性的新坑。更务实的方案是半开时的请求加上指数退避延时，或者让半开只发生在单实例，灰度放量。

坑二：异常类型不该一视同仁

HTTP 503 和 IllegalStateException 能一样吗？前者是下游扛不住，熔断天经地义；后者是你自己的代码 bug，熔断个毛线。一定要只针对特定异常熔断。Resilience4j 的 recordExceptions 和 ignoreExceptions 配置很容易忽略。我见过一个订单系统因为没有忽略 NullPointerException，结果大量空指针全都走了降级，整个业务挂了半小时才发现是代码上线导致的——傻不傻？

坑三：降级逻辑不能变成隐藏炸弹

熔断后的降级方法，很多人就返回个默认值。但如果默认值会导致业务逻辑继续走到写库，然后产生脏数据呢？有一回我们降级返回了空库存，结果下单链路把他的购物车全清空了——因为空库存触发了“自动清除无效商品”的逻辑。这连锁反应，惊不惊喜？降级必须是最小化副作用，甚至在某些场景下直接返回错误，让上层显式处理。

说到底，熔断器是一个快速失败的信使。它不修理任何东西，只是告诉你：这里大概率出问题了，别再硬等了。而实现得好的熔断器，就像神经网络——看似简单的阈值，背后是精巧的统计。它美就美在，用最少的状态，刻画了最不确定的世界。