1. 熔断器模式概述
1.1 熔断器模式的定义
熔断器模式(Circuit Breaker Pattern)是一种用于分布式系统的弹性设计模式,其核心思想是通过状态机自动控制对远程服务或资源的调用行为,防止级联故障扩散。当被调用的服务持续失败达到阈值时,熔断器“断开”链路,直接快速失败而非继续等待超时;经过冷却时间后,熔断器进入“半开”状态,允许少量探测请求验证服务是否恢复,从而决定完全闭合或再次断开。
核心目标: 快速失败 + 自我修复,避免线程/连接资源被长时间阻塞,保护调用方自身稳定性。
1.2 在微服务中的重要性
微服务架构中,服务间依赖关系复杂,单个服务故障可能通过同步调用链迅速放大,形成雪崩效应。熔断器模式在以下场景中发挥关键作用:
- 隔离故障边界: 下游服务超时或异常时,熔断器立即切断调用,防止调用方线程池耗尽。
- 快速失败与降级: 熔断状态下直接返回降级响应(如缓存数据、默认值),避免用户长时间等待。
- 自动恢复探测: 半开状态提供安全的自愈机制,无需人工介入即可恢复服务。
- 资源保护: 减少对故障服务的无效重试,降低网络和CPU开销。
实践建议: 熔断器应部署在调用链的入口处(如API网关、BFF层)以及关键依赖的客户端侧,实现分层保护。
1.3 熔断器与重试、限流的区别
熔断器、重试、限流是分布式系统弹性设计的三大基础模式,但三者关注点不同,常配合使用。下表从多个维度进行对比:
| 对比维度 | 熔断器 | 重试 | 限流 |
|---|---|---|---|
| 核心目标 | 防止级联故障,快速失败 | 补偿临时性失败,提高成功率 | 控制请求速率,保护系统容量 |
| 触发条件 | 连续失败次数/比例达阈值 | 特定异常(如超时、网络抖动) | 请求速率/并发数超过阈值 |
| 动作行为 | 断开调用链路,直接返回降级 | 等待间隔后重新发送请求 | 排队、拒绝或丢弃请求 |
| 状态管理 | 闭合 → 断开 → 半开 → 闭合 | 无状态,每次独立判断 | 滑动窗口/令牌桶等计数器 |
| 适用场景 | 下游服务持续故障或过载 | 偶发、短暂的网络或服务抖动 | 流量突增、防止资源耗尽 |
| 副作用风险 | 可能延迟恢复探测 | 重试风暴加剧负载 | 可能丢弃正常请求 |
常见误区: 熔断器与重试不能简单叠加使用。在熔断器断开状态下,应禁止任何重试逻辑;在半开状态下,仅允许探测请求重试。建议在重试策略中集成熔断器状态检查。
1.4 熔断器状态机与核心流程
下图展示了熔断器的三态转换模型,这是理解半开状态的基础:
1.4 熔断器与重试、限流的协作关系
在实际生产环境中,三种模式通常组合使用,形成完整的弹性防护层。下图展示了典型的协作架构:
1.5 关键设计要点
- 失败计数窗口: 通常使用滑动窗口(如最近10秒内)统计失败率,避免瞬时波动导致误断。
- 半开探测策略: 探测请求数量应远小于正常流量(如1~3个),且需设置独立的超时阈值。
- 降级响应设计: 熔断触发后必须提供有意义的降级数据(如缓存、默认值、错误提示),不能直接抛出异常。
- 指标监控: 必须暴露熔断器状态、失败次数、探测次数等指标,用于告警和容量规划。
生产建议: 熔断器阈值应根据服务SLA动态调整。对于核心支付链路,失败阈值可设为2次/10秒;对于非关键查询服务,可放宽至10次/30秒。