一篇读懂熔断器：从雪崩到自我保护

下游服务变慢时，上游的调用线程被阻塞，线程池耗尽后整个服务不可用——故障沿着调用链向上游传播，最终全站雪崩。熔断器（Circuit Breaker）就是切断了这条传播链的安全装置：它的名字来自电路中的保险丝——检测到电流过大时自动断开，保护整个电路。在微服务语境下，熔断器「检测到下游持续失败时自动断开调用」，给下游恢复的时间。本篇讲清熔断器的三态模型、与限流/降级的协作。

三态模型：关闭、打开与半开

关闭（Closed）：正常状态，请求正常通过。熔断器维护一个滑动窗口，统计最近 N 次请求的失败率——失败率低于阈值（如 50%）时保持关闭。打开（Open）：失败率超过阈值时熔断器「跳闸」——所有后续请求直接失败（快速失败），不再调用下游。打开状态有超时时间（如 30 秒），超时后自动进入半开状态。半开（Half-Open）：放行少量探测请求（如 5 个）到下游，测试其是否恢复——全部成功则回到关闭状态，任一失败则重新打开。

class CircuitBreaker:
    def __init__(self, failure_threshold=0.5, min_requests=10,
                 open_timeout=30):
        self.failure_threshold = failure_threshold   # 失败率阈值
        self.min_requests = min_requests             # 最少请求数
        self.open_timeout = open_timeout             # 打开态超时（秒）
        self.state = "closed"
        self.failures = 0
        self.requests = 0
        self.opened_at = None

    def allow_request(self) -> bool:
        if self.state == "open":
            if time.time() - self.opened_at > self.open_timeout:
                self.state = "half_open"             # 超时后进入半开
            else:
                return False                          # 仍打开：快速失败
        return True

    def record_success(self):
        self.failures = max(0, self.failures - 1)
        self.requests += 1
        self._check_state()

    def record_failure(self):
        self.failures += 1
        self.requests += 1
        self._check_state()

    def _check_state(self):
        if self.state == "half_open":               # 半开失败 → 重新打开
            self.state = "open"
            self.opened_at = time.time()
        elif (self.requests >= self.min_requests and
              self.failures / self.requests > self.failure_threshold):
            self.state = "open"                     # 关闭态失败率超标 → 打开
            self.opened_at = time.time()

熔断 + 降级 + 限流：高可用三件套的协作

熔断器不会单独工作，它与降级（fallback）和限流（rate limiting）组成高可用三件套。熔断 + 降级：熔断打开后请求直接失败，但「失败」不等于「给用户报错」——熔断器通常搭配 fallback 函数，在熔断打开时返回降级结果（缓存数据、默认值、友好提示），用户体验从「报错」降级为「功能受限」。限流：熔断器是「被动防御」（检测到下游失败才断开），限流器是「主动防御」（限制请求速率不超过下游容量，本库《一篇读懂限流器》详述）——限流在故障发生前预防过载，熔断在故障发生后止损——两者协作的顺序：限流先拦（控制入口速率），限流拦不住的过载导致下游异常，熔断再断（切断调用链），熔断期间降级兜底（用户体验不断崖）。

Resilience4j 的实践

Java 生态的主流熔断库是 Resilience4j（Hystrix 已停止维护）——它将熔断器设计为函数式装饰器，与 Spring Boot 无缝集成：

CircuitBreakerConfig config = CircuitBreakerConfig.custom()
    .failureRateThreshold(50)          // 失败率阈值 50%
    .slidingWindowSize(10)             // 滑动窗口 10 次请求
    .waitDurationInOpenState(Duration.ofSeconds(30))
    .build();
CircuitBreaker cb = CircuitBreaker.of("paymentService", config);

// 装饰器模式：用熔断器包装调用
Supplier<String> decorated = CircuitBreaker
    .decorateSupplier(cb, () -> paymentService.charge(order));

// 搭配 fallback
String result = Try.ofSupplier(decorated)
    .recover(CallNotPermittedException.class, "服务繁忙，请稍后重试")
    .get();

关键配置参数：失败率阈值（默认 50%）、滑动窗口类型（计数或时间）、最少请求数（避免低流量时的误判——10 个请求中 6 个失败 = 60% 超过阈值，但样本太小可能只是偶发）、半开时的探测请求数（默认 10 个）。

熔断器的舱壁隔离模式：不同下游独立熔断

熔断器不应全局共用一个实例——如果所有下游调用共用一个熔断器，一个下游的故障会导致所有下游调用的熔断（误伤健康的下游）。舱壁隔离模式：为每个下游服务维护独立的熔断器实例与线程池或信号量——一个下游的故障只影响自己的熔断器。Resilience4j 的实现：每个 CircuitBreaker 实例绑定一个服务名，配合 ThreadPoolBulkhead 或 SemaphoreBulkhead 实现资源隔离。舱壁隔离的名字来源：船舱的防水隔板——一个舱进水不影响其他舱。与限流的配合：舱壁隔离限制的是并发数，限流限制的是速率——两者互补（舱壁防并发过载，限流防速率过载）。

熔断器的「慢调用」检测：不只是错误率

熔断器的传统检测只看「错误率」，但「慢调用」同样危险——一个每次调用耗时 30 秒但最终成功的下游，比一个快速返回 500 的下游更危险（占住了线程池的线程）。Resilience4j 1.4+ 引入了慢调用率（slow call rate）的检测：除了失败率阈值，还可以配置「慢调用阈值」（如超过 2 秒视为慢调用）与「慢调用比例阈值」（如慢调用超过 80% 则打开熔断器）。慢调用熔断的意义：慢调用的线程占用会导致上游的线程池耗尽（每个慢调用占住一个线程 30 秒），最终上游因为线程池耗尽而不可用——这就是「雪崩」的典型路径。熔断器检测慢调用的配置：slowCallDurationThreshold(Duration.ofSeconds(2)) 与 slowCallRateThreshold(80)——超过 2 秒的调用视为慢调用，慢调用比例超过 80% 时打开熔断。慢调用检测与错误率检测是并行的——任一超标都触发熔断。

熔断器的慢调用检测：不只是错误率

熔断器的传统检测只看错误率但慢调用同样危险——一个每次调用耗时 30 秒但最终成功的下游比一个快速返回错误的下游更危险。Resilience4j 1.4 加入了慢调用率的检测：除了失败率阈值还可以配置慢调用阈值如超过 2 秒视为慢调用与慢调用比例阈值如慢调用超过 80% 则打开熔断器。慢调用熔断的意义：慢调用的线程占用会导致上游的线程池耗尽——这就是雪崩的典型路径。熔断器检测慢调用的配置：slowCallDurationThreshold 设为 2 秒与 slowCallRateThreshold 设为 80——超过 2 秒的调用视为慢调用慢调用比例超过 80% 时打开熔断。慢调用检测与错误率检测是并行的任一超标都触发熔断。

熔断器与限流的协作：高可用三件套

熔断器不会单独工作，它与降级和限流组成高可用三件套。熔断加降级：熔断打开后请求直接失败但失败不等于给用户报错——熔断器搭配 fallback 函数在熔断打开时返回降级结果（缓存数据、默认值、友好提示）。限流：熔断器是被动防御（检测到下游失败才断开）限流器是主动防御（限制请求速率不超过下游容量）。协作的顺序：限流先拦控制入口速率、限流拦不住的过载导致下游异常熔断再断切断调用链、熔断期间降级兜底用户体验不断崖。

熔断器的「指标与事件」可观测性

熔断器的状态变化与统计指标需要暴露为可观测的数据。熔断器的指标包括状态（closed/open/half_open）、失败率（滑动窗口内）、慢调用率、总请求数——通过 Micrometer 暴露给 Prometheus 与 Grafana。熔断器的事件：状态变化事件（CLOSED 到 OPEN、OPEN 到 HALF_OPEN、HALF_OPEN 到 CLOSED）——状态变化事件应该触发告警（熔断器打开意味着下游不可用或过载）。Resilience4j 的事件系统：注册 CircuitBreakerEventConsumer 监听状态变化事件。Grafana 面板的设计：每个熔断器一个面板展示状态、失败率、慢调用率、QPS、延迟分位数——状态变化用垂直线标注在时间线上。

限流、熔断与降级的「决策树」：面对过载的完整应对策略

面对系统过载，限流、熔断与降级组成一个完整的应对策略决策树。第一步：限流（入口层控制——本库《限流器》的令牌桶或滑动窗口算法限制请求速率不超过系统容量）。第二步：熔断（下游不可用时切断调用链——避免故障沿着调用链传播导致雪崩）。第三步：降级（熔断后返回降级结果——缓存数据、默认值、友好提示——用户体验从「报错」降级为「功能受限」）。三者的顺序：限流预防过载、熔断隔离故障、降级兜底体验——三者协作的顺序不可颠倒。最终目标：让系统在过载时「有损但不崩」——一部分用户得到降级服务，另一部分用户正常服务，系统整体保持可用。

熔断器的指标可观测性与事件告警

熔断器的状态变化与统计指标需要暴露为可观测的数据。熔断器的指标包括状态、失败率、慢调用率、总请求数——通过 Micrometer 暴露给 Prometheus 与 Grafana。熔断器的事件：状态变化事件如从 CLOSED 到 OPEN 或 OPEN 到 HALF_OPEN——状态变化事件应该触发告警。Resilience4j 的事件系统：注册 CircuitBreakerEventConsumer 监听状态变化事件。Grafana 面板的设计：每个熔断器一个面板展示状态与失败率与延迟分位数——状态变化用垂直线标注在时间线上——一眼看出什么时候熔断了持续了多久什么时候恢复。

熔断器的 Resilience4j 实践代码

Java 生态的主流熔断库是 Resilience4j（Hystrix 已停止维护），它将熔断器设计为函数式装饰器。与 Spring Boot 无缝集成的代码示例。CircuitBreakerConfig 配置失败率阈值 50% 滑动窗口 10 次请求打开态超时 30 秒。CircuitBreaker 创建实例并装饰 Supplier。搭配 fallback 使用 Try.ofSupplier(decorated).recover(CallNotPermittedException.class 降级响应)。关键配置参数包括失败率阈值默认 50% 滑动窗口类型计数或时间最少请求数避免低流量误判半开时的探测请求数。Resilience4j 还支持 RateLimiter 限流器 Bulkhead 舱壁 Retry 重试 TimeLimiter 超时等模块可以组合使用形成完整的容错方案。

熔断器的可观测性与事件告警

熔断器的状态变化与统计指标需要暴露为可观测的数据。熔断器的指标包括状态失败率慢调用率总请求数通过 Micrometer 暴露给 Prometheus 与 Grafana。熔断器的事件状态变化事件从 CLOSED 到 OPEN 或 OPEN 到 HALF_OPEN 或 HALF_OPEN 到 CLOSED——状态变化事件应该触发告警。Resilience4j 的事件系统注册 CircuitBreakerEventConsumer 监听状态变化事件。Grafana 面板的设计每个熔断器一个面板展示状态失败率慢调用率 QPS 延迟分位数——状态变化用垂直线标注在时间线上。

Resilience4j 的模块化设计与实践代码

Resilience4j 的设计理念是模块化的轻量容错库——除了熔断器还有多个容错模块可以组合使用。Retry 重试自动重试失败的调用可配置重试次数等待策略重试的异常类型。RateLimiter 限流器限制调用的速率令牌桶算法。Bulkhead 舱壁限制并发数线程池隔离或信号量隔离。TimeLimiter 超时为异步调用设置超时。模块的组合这些模块可以以装饰器模式叠加使用每一层独立配置独立监控独立开关。Resilience4j 的函数式设计装饰器模式比 Hystrix 的继承模式更灵活不需要继承特定类。Spring Boot 集成 spring-cloud-starter-circuitbreaker-resilience4j 提供了声明式的注解。

小结

熔断器收成四条：三态模型——关闭（正常通过）、打开（快速失败 + 降级兜底）、半开（少量探测测试恢复）；熔断 + 降级 + 限流是高可用三件套——限流预防过载、熔断切断故障传播、降级保证用户体验不断崖；Resilience4j 是 Java 生态的主流熔断库——函数式装饰器设计，与 Spring Boot 无缝集成；熔断器的配置参数（失败率阈值、滑动窗口、最少请求数）需要按下游的特性调优——不能一套参数打天下。熔断器的价值不是「让服务不出错」，是「让错误在可控范围内、给恢复留时间」——它是分布式系统的保险丝，小而不可或缺。

参考资料

• Resilience4j 官方文档 —— 熔断器、限流器与重试的 Java 实现
• Michael Nygard, 《Release It!》—— Circuit Breaker 模式的原始出处
• 本库前篇：《一篇读懂限流器》《LLM 应用的可观测性》