熔断器模式：从“雪崩”到“自我修复”
大家好，我是老张。今天我们来聊聊熔断器模式。
说实话，我第一次接触这个模式，是在一次线上事故之后。那会儿系统突然就挂了，查了半天才发现，是下游的一个服务响应慢了，结果整个调用链都堵死了。嗯，这就是典型的“雪崩效应”。
熔断器，说白了就是给系统装一个“保险丝”。当某个服务出问题时，它能快速切断调用，而不是让请求一直等下去。你想想看，这跟家里的电闸是一个道理——电流过载了，保险丝先断，保护整个电路。
熔断器的三态：关闭、打开、半开
熔断器有三个状态，我习惯叫它“三态模型”。
- 关闭状态：正常情况。请求照常通过，熔断器默默统计失败率。
- 打开状态：出问题了。失败率超过阈值，熔断器直接切断所有请求，快速返回错误。
- 半开状态：试探阶段。过了一段时间，熔断器放一个请求过去试试，看看下游恢复没有。
这三个状态是怎么切换的呢？我画了一张图，你看一眼就明白了。
这个流程我建议你记牢了。我在项目中见过不少同学，只配置了阈值，却忘了设置半开状态的试探间隔，结果熔断器打开了就再也回不来了。
Hystrix vs Resilience4j：两个时代的产物
说到熔断器的实现，绕不开两个库：Hystrix 和 Resilience4j。
Hystrix 是 Netflix 开源的，曾经是业界标准。但后来 Netflix 宣布 Hystrix 进入维护模式，不再开发新功能了。为什么呢？我个人觉得，Hystrix 的设计太重了——它用了线程池隔离，每个依赖一个线程池，管理起来很麻烦。
Resilience4j 是后来者，设计理念更轻量。它用了信号量隔离，没有线程切换的开销。说白了，就是更省资源。
我整理了一个对比表格，你一看就明白。
| 对比项 | Hystrix | Resilience4j |
|---|---|---|
| 隔离方式 | 线程池隔离（每个依赖一个线程池） | 信号量隔离（轻量，无线程切换） |
| 熔断器状态 | 三态（关闭、打开、半开） | 三态（关闭、打开、半开） |
| 配置方式 | 注解 + properties 文件 | 注解 + Java DSL / yaml |
| 性能开销 | 较高（线程池切换） | 较低（无线程切换） |
| 维护状态 | 维护模式（不再开发新功能） | 活跃维护（持续更新） |
| 适用场景 | 老项目、已有 Hystrix 依赖 | 新项目、追求轻量高性能 |
我的建议：如果你在写新项目，直接上 Resilience4j。Hystrix 虽然稳定，但已经停止更新了。我去年接手过一个老项目，还在用 Hystrix，想升级 Spring Boot 版本，结果发现 Hystrix 不兼容，折腾了好几天。
熔断阈值配置：到底设多少合适？
阈值配置是个技术活。设得太低，容易误伤；设得太高，又起不到保护作用。
我一般会关注三个核心参数：
- 失败率阈值：比如 50%，意思是 10 个请求里有 5 个失败，就熔断。
- 请求数阈值：比如 20 个，意思是至少统计 20 个请求，才判断失败率。
- 半开试探间隔：比如 5 秒，意思是熔断后等 5 秒，再放一个试探请求。
举个例子，用 Resilience4j 配置一下：
// Resilience4j 熔断器配置示例
CircuitBreakerConfig config = CircuitBreakerConfig.custom()
.failureRateThreshold(50) // 失败率阈值 50%
.slidingWindowSize(20) // 滑动窗口大小 20 个请求
.minimumNumberOfCalls(10) // 最少请求数 10 个
.waitDurationInOpenState(Duration.ofSeconds(5)) // 半开前等待 5 秒
.permittedNumberOfCallsInHalfOpenState(3) // 半开时允许 3 个试探请求
.build();
CircuitBreaker circuitBreaker = CircuitBreaker.of("myService", config);
避坑指南：我曾经把失败率阈值设成了 10%，结果线上稍微有点波动就熔断了，用户反馈说“系统怎么老报错”。后来我改成 50%，配合滑动窗口，效果就好多了。记住，阈值要根据实际业务调整，没有“万能值”。
还有一个容易忽略的点：滑动窗口类型。Resilience4j 支持两种：基于计数和基于时间。我建议用基于计数的，更直观。基于时间的窗口，如果请求量不均匀，统计结果可能不准确。
小结
熔断器模式，说白了就是给系统加一道保险。三态模型是核心，Hystrix 和 Resilience4j 是工具，阈值配置是经验活。
嗯，今天的内容就到这里。记住一句话：熔断不是目的，保护系统才是。