什么是熔断器？为什么需要熔断器？
- 标签：服务容灾、Spring Cloud、微服务、后端
🏛 业务架构师
熔断器（Circuit Breaker）是微服务调用链上的自动保险丝：持续失败时主动"跳闸"，后续调用快速失败（不再真正发起远程请求），过一段时间半开试探恢复——防止持续把请求打向已经故障的服务。
为什么需要它——用业务事故讲：
支付服务 DB 抖动，RT 从 50ms 涨到 30s。没有熔断时：上游订单服务的 200 个工作线程全部阻塞在支付调用上（同步等待超时）——订单服务自身线程池耗尽，连不依赖支付的接口也瘫了；它再传染上游……最终一个非核心依赖拖垮整条交易链。这就是服务雪崩：故障沿调用链向上蔓延，核心业务整体不可用。
熔断器的工作机制（三状态机）：
- 关闭（正常）：放行请求，统计失败率/慢调用比例；
- 打开（熔断）：失败率超阈值（如 10 秒内 50%）→ 直接拒绝，毫秒级失败 + 走降级逻辑，保护自己线程不被拖死；
- 半开（试探）：冷却期后放少量请求探测，成功则恢复、失败则继续熔断。
架构师视角的定位：熔断本质是**"用快速失败换系统存续"**——拒绝请求当然损业务，但雪崩是全站资损 + 恢复漫长；熔断把故障半径锁定在单一功能点。配套组合拳：熔断（故障隔离）+ 限流（过载保护）+ 降级（兜底体验）+ 隔离舱（不同依赖独立线程池/信号量，防互相挤占）。现役方案：Sentinel（国内默认）或 Resilience4j（Hystrix 已退役）。
🏗 系统架构师
定义：熔断器是自动化的故障隔离开关——统计下游调用的错误率与慢调用率，超过阈值后快速失败（不再真正调用），一段时间后半开试探，恢复则闭合。
为什么必须要有（算一笔账）：下游 P99 恶化到 5s，我的 Tomcat 200 线程——约 40 QPS 就能打满全部线程（200÷5）。一个下游的故障瞬间耗尽我的全部并发容量，我依赖的其他服务也被拖死，这就是雪崩的数学本质。熔断把「等 5s 超时」变成「1ms 内失败」，线程资源保住，系统整体活下来。
架构要点：
- 熔断必须与超时、重试预算、舱壁隔离组合：熔断防雪崩、超时防挂起、舱壁防独占——单靠任何一个都不完整；
- 阈值按依赖 SLO 定（如 10s 窗口错误率超 50% 熔断 30s），半开放小流量探测防抖动；
- 降级策略先想好（兜底值、缓存、异步补偿）——没有降级的熔断只是把错误换了个姿势；
- 实现：Sentinel 熔断规则或 Resilience4j CircuitBreaker，熔断状态变化接告警——熔断是止血，根因要人跟。
💻 全栈开发专家
熔断器（Circuit Breaker）是防止故障级联放大的保护开关：依赖方错误率/慢调用比例超阈值时自动"跳闸"——一段时间内对该依赖的调用直接快速失败走降级，不再真发请求，给下游喘息恢复的时间。
为什么需要：没有熔断时，下游 DB 慢 → 服务线程全阻塞在等响应 → 线程池耗尽 → 本服务无响应 → 上游接着被拖死——雪崩传导。熔断在链条中间主动切断，把故障隔离在局部。
三状态机：
- CLOSED：正常放行，同时统计滑动窗口内错误率/慢调用比例
- OPEN：阈值触发（如错误率 > 50%），所有请求快速失败走 fallback
- HALF_OPEN：冷却期（如 10s）后放少量探测请求，成功回 CLOSED，失败保持 OPEN
Spring Cloud 接入二选一：Sentinel（慢调用比例/异常比例/异常数三种策略，控制台实时管理）或 Resilience4j（spring-cloud-circuitbreaker-resilience4j，配 slidingWindowSize/failureRateThreshold）。
关键配套：熔断必须配降级方法（fallback 给兜底数据），且告警要盯状态跳变——熔断打开不是异常，是防御动作生效的信号。