断路器模式通过状态驱动与阈值控制主动熔断，含CLOSED、OPEN、HALF_OPEN三态：CLOSED统计异常并达阈值转OPEN；OPEN拒绝请求并降级；HALF_OPEN试探恢复。需配置统计粒度、明确定义异常范围，配套降级、监控与人工干预，并与重试解耦。
断路器模式不是等异常发生后再补救，而是通过持续观测调用行为，在连续异常达到临界点时主动切断请求流，防止资源耗尽和故障扩散。核心在于“状态驱动”和“阈值控制”，而不是单纯响应单次错误。
状态切换是熔断逻辑的执行骨架
断路器靠三种状态协同工作，每种状态对应明确的行为边界：
- CLOSED（闭合）：默认状态。所有请求正常转发，同时实时统计失败次数、超时次数或响应延迟。一旦失败率（如10秒内失败5次）或失败数（如连续7次）触达预设阈值，立即转入OPEN状态。
- OPEN（打开）：拒绝所有新请求，不发往下游服务。直接返回降级结果（如缓存数据、默认值、友好提示），避免线程阻塞与连接堆积。该状态会持续一段固定时间（如60秒），由“超时时间”参数控制。
- HALF_OPEN（半开）：OPEN超时后自动进入。只放行少量试探性请求（如最多3个），用于验证下游是否恢复。若全部成功，则切回CLOSED；只要有一个失败，立刻重置为OPEN。
连续异常如何被识别和计数
“连续异常”不是指时间上紧挨着的失败，而是单位时间窗口内的累计异常事件。实际实现中关键看两点：
- 统计粒度可配置：支持按请求数（如最近20次中失败≥8次）、按时间窗口（如60秒内失败≥5次）、或按失败率（如错误率＞50%持续30秒）触发。不同业务场景应选不同策略——支付类接口适合强失败率控制，日志上报类可放宽为次数阈值。
- 异常范围需明确定义：不仅包括HTTP 5xx、连接超时、读取超时，也应纳入业务异常码（如库存不足返回409）。但400/401这类客户端错误通常不计入熔断统计，避免误熔断。
熔断后必须配套降级与可观测能力
熔断本身只是“断”，真正保障可用性的是后续动作：
- 降级策略要提前注册：比如调用用户服务失败时，返回本地缓存的用户头像和昵称；调用优惠券服务失败时，跳过折扣计算，按原价下单。降级逻辑必须无外部依赖、执行快、结果可接受。
- 状态变更必须可监控：每次状态切换（CLOSED→OPEN、OPEN→HALF_OPEN等）都应打日志，并上报指标（如circuit_breaker_state{service="order", target="inventory"}）。运维可通过Prometheus+Grafana观察熔断频次与持续时间，判断下游稳定性问题。
- 人工干预通道要保留：提供API或管理界面，允许紧急手动关闭熔断（force close）或强制开启（force open），应对灰度发布、压测等特殊场景。
和重试机制必须解耦使用
重试会放大问题，断路器要限制重试——这是容易出错的关键点：
- 在CLOSED状态下，可对瞬时网络异常做1~2次重试；但对已进入OPEN状态的服务，禁止任何重试，否则等于绕过熔断。
- 半开状态下的试探请求，本身不带重试；若失败，直接回切OPEN，不尝试补偿。
- 建议将重试逻辑放在断路器外层（如Feign Client配置），断路器只负责“是否允许发起请求”，不参与重试决策。
