熔断器模式 (Circuit Breaker)

引言：“级联失效”问题

在微服务架构中，服务 A 调用服务 B。如果服务 B 响应变慢，服务 A 的线程就会开始堆积等待。很快，服务 A 耗尽内存并崩溃。接着，调用服务 A 的服务 C 也会跟着崩溃。这就是 级联失效 (Cascading Failure)。

熔断器 就像家里电路的保险丝。如果某个服务开始频繁报错，熔断器就会“跳闸”，停止所有对该服务的调用，给它喘息和恢复的时间，同时向用户返回一个优雅的降级错误。

算法要解决什么问题？

• 输入： 服务调用的成功/失败信号。
• 输出： 连接的状态（关闭, 开启, 或 半开）。
• 承诺： 稳定性。防止单一组件的故障拖垮整个系统。

核心状态 (工作原理)

1. 关闭 (Closed - 健康)： 一切正常，流量正常流向服务。
2. 开启 (Open - 故障)： 如果失败率超过阈值（如 1 分钟内 50% 失败），熔断器就会 跳闸 (开启)。后续所有请求都会立即失败，不再发往故障服务。
3. 半开 (Half-Open - 探测)： 在等待一段时间（如 30 秒）后，熔断器允许 少量 测试请求通过。
   • 如果成功：熔断器恢复到 关闭 状态。
   • 如果失败：重新回到 开启 状态。

服务降级 (Fallback)：“B 计划”

当熔断器开启时，系统不应只显示冰冷的“500 错误”，而应执行 降级逻辑：

• 默认值： “功能暂时不可用，请稍后再试”。
• 静态缓存： 显示上一次成功获取的旧数据。
• 简化逻辑： 比如关闭“个性化推荐”板块，但保证基础商品详情能正常显示。

典型业务场景

• ✅ 支付网关： 如果支付服务宕机，熔断器跳闸，前端提示“支付功能维护中”，防止用户瘋狂點擊提交。
• ✅ 微服务通信： 保护高负载的搜索服务，当其数据库压力过大时自动限流。
• ✅ 第三方 API： 避免在对方 API 报错期间继续调用，浪费配额或增加成本。

性能与复杂度总结

• 开销： 极低。它只是一个带有计数器的状态机。
• 工具： Resilience4j, Netflix Hystrix (已過時), 或 Istio 等 Service Mesh 自带的熔断功能。

小结：一句话记住它

“熔断器是云端的‘保险丝’。它阻止你往火坑里继续添柴，给那些摇摇欲坠的服务一个呼吸和重生的机会。”