📚 课程目录第3章熔断机制原理

3、熔断机制原理：断路器模式

熔断机制这词儿一出来，很多人第一反应是电路里的保险丝。没错，微服务里的熔断器，思路就是从那儿借来的。说白了，就是当你调用下游服务时，如果对方老是出问题，你不能傻等、不能死磕，得主动切断通路，防止故障像多米诺骨牌一样倒成一片。

我最早接触熔断是在做支付网关的时候。那次上游渠道响应慢，结果整个线程池被打满，连健康检查请求都排不上队——嗯，整个服务直接“雪崩”。复盘完之后，我第一件事就是翻出Hystrix的文档，把断路器装了上去。

3.1 断路器模式的核心思想

断路器模式，其实就是一个带状态的开关。它帮你记录调用失败的次数、比例，一旦超过阈值，就自动跳闸。跳闸之后，后续请求不再真正发起远程调用，而是快速失败（fail-fast）或者走降级逻辑。等过一段时间，它会再试探一下——看看下游恢复没有。恢复了就闭合，没恢复就继续断开。

关键目标：隔离故障 + 快速失败 + 自动恢复。不是“不调用”，而是“有策略地调用”。

3.2 状态机：关闭、打开、半开

断路器的内部状态机非常经典，只有三个状态：关闭（Closed）、打开（Open）、半开（Half-Open）。别小看就三个状态，背后的逻辑值得细抠。

状态	含义	行为	触发条件
关闭	正常工作，请求全部通过	统计失败次数/比例，超过阈值就切换到打开	失败率 ≥ 阈值（如50%）且请求量 ≥ 最小请求数
打开	熔断中，直接拒绝请求	快速失败或执行降级Fallback，等待超时后进入半开	从关闭状态触发，熔断时间窗口到期
半开	试探阶段，放行少量请求	若试探请求成功，切回关闭；若失败，回到打开并重置计时	熔断时间结束，自动进入

我在项目中遇到过一个问题：阈值设得太低，偶尔网络抖动就跳闸了。后来我改成“滑动窗口内失败率+最小请求数”双条件，才稳定下来。你想想看，如果只按次数算，高峰期一下就被打满，其实不合理。

3.3 流行的实现：Hystrix 与 Resilience4j

Hystrix 是 Netflix 开源的，曾经是熔断降级的代名词。不过它已经进入维护模式了，官方推荐迁移到 Resilience4j。我个人习惯在新项目里直接用 Resilience4j，轻量、模块化、对 Java 8 函数式编程很友好。

3.3.1 Hystrix（了解为主）

Hystrix 使用线程池隔离或者信号量隔离。它的断路器默认参数：10秒内请求数 ≥20，失败率 ≥50% 就打开，熔断5秒后进入半开。虽然老，但设计思路值得学习。

// HystrixCommand 示例（简化）
public class MyCommand extends HystrixCommand<String> {
    protected MyCommand() {
        super(HystrixCommandGroupKey.Factory.asKey("MyGroup"));
    }

    @Override
    protected String run() throws Exception {
        // 真正的远程调用
        return remoteService.call();
    }

    @Override
    protected String getFallback() {
        return "fallback-result";
    }
}

小提示：Hystrix 默认的隔离策略是线程池隔离，好处是调用方线程不会被阻塞；缺点是每个Command都要占用线程资源。如果服务实例数很多，线程开销不可忽视。

3.3.2 Resilience4j（推荐主力）

Resilience4j 的断路器设计得更灵活。它支持基于滑动窗口、基于计数、以及基于时间窗的统计。还提供了单独的模块：限流器、重试、舱壁、缓存等，你可以按需引入。

// Resilience4j 断路器配置
CircuitBreakerConfig config = CircuitBreakerConfig.custom()
    .slidingWindowSize(10)          // 滑动窗口大小
    .minimumNumberOfCalls(5)        // 最少请求数
    .failureRateThreshold(50)       // 失败率阈值 %
    .waitDurationInOpenState(Duration.ofMillis(5000)) // 熔断持续时间
    .halfOpenOpenThreshold(1)       // 半开时允许的请求数
    .build();

CircuitBreaker circuitBreaker = CircuitBreaker.of("myService", config);

// 装饰你的调用
Supplier<String> decorated = CircuitBreaker.decorateSupplier(circuitBreaker, 
    () -> remoteService.call());
Try<String> result = Try.ofSupplier(decorated)
    .recover(throwable -> "fallback");

避坑指南：我曾经把 slidingWindowSize 设成 100，minimumNumberOfCalls 设成 50，结果小流量的时候断路器几乎不生效。后来改成20和5，才在低流量下也能正常熔断。参数不是越大越好，得结合你业务的 QPS 来设计。

3.4 状态流转全过程（一张图说明白）

下面这张 SVG 图把三个状态和转移条件画清楚了。你看一眼就能记住。

3.5 一些要命的参数细节

除了状态机，还有一些参数直接决定了熔断器的“脾气”。我把常用的参数整理了一下，你调优时可以参考。

参数	说明	建议值（仅供参考）	常见坑
`slidingWindowSize`	滑动窗口大小（请求数或时间）	10 ~ 20	设太大→响应迟钝；设太小→误熔断
`minimumNumberOfCalls`	触发统计的最小请求数	5 ~ 10	低于此值不判断，低流量时熔断失效
`failureRateThreshold`	失败率阈值（百分比）	50 ~ 60	设太低→抖动即熔断；设太高→无保护
`waitDurationInOpenState`	熔断持续时间	5 ~ 10 秒	太短→频繁试探；太长→恢复慢
`halfOpenOpenThreshold`	半开时允许的试探请求数	1 ~ 3	太大→压力集中；太小→探测不充分

核心原则：先保守（阈值稍高、窗口适中），上线后根据监控数据逐步调低。我曾经一上来就设了30%失败率熔断，结果灰度发布一次就跳闸——其实只是流量倾斜导致瞬时失败。后来改成50% + 滑动窗口10个请求，稳多了。

3.6 什么时候不该用熔断

熔断不是银弹。我见过有人把熔断用在本地内存操作上——那根本没必要。熔断主要针对依赖的外部服务、数据库、缓存等有网络IO的场景。如果调用是纯本地函数，用限流或超时就行，不必引入断路器那套状态管理。

多说一句：熔断后的降级策略一定要测试。Fallback不能只写个“null”或者抛异常，得真的有一次可替代的返回。否则熔断打开后，你的服务虽然不阻塞了，但返回的数据不对，一样会炸。

嗯，这一章就讲到这里。你动手配置的时候，不妨先拿一个不太关键的接口练手，把参数调熟，再推广到核心链路。代码里多打点日志，配合监控看状态变化，比纸上谈兵有用得多。