3. 熔断基础理论：熔断器三态模型与恢复策略
在金融模型服务中，熔断机制是防止级联故障、保障系统弹性的核心手段。其设计灵感来源于电路中的断路器：当电流异常时自动断开，保护电路；待故障消除后自动尝试恢复。本节将深入剖析熔断器的三态模型、触发条件与恢复策略，为后续实战编码奠定理论基础。
3.1 熔断器三态模型（Closed / Open / Half-Open）
熔断器在运行过程中维护三个核心状态，形成一个有限状态机。每个状态决定了请求是否被允许通过，以及系统如何监控后端健康状况。
核心概念： 熔断器不是简单的“开/关”二元状态，而是通过 Closed → Open → Half-Open → Closed 的循环，实现自动化的故障隔离与恢复。
3.2 三态详细行为对比
| 状态 | 请求处理方式 | 统计窗口 | 典型触发条件 | 恢复策略 |
|---|---|---|---|---|
| Closed | 正常转发请求到后端 | 滑动窗口持续统计失败率 | 失败率 > 阈值（如 50%） | 进入 Open 状态 |
| Open | 快速失败，直接返回降级响应 | 停止统计，启动超时计时器 | 计时器到期（如 30 秒） | 进入 Half-Open 状态 |
| Half-Open | 允许有限数量的探测请求通过 | 仅统计探测请求结果 | 探测请求成功率达到阈值 | 回到 Closed；否则回到 Open |
3.3 熔断触发条件详解
熔断器从 Closed 切换到 Open 并非仅依赖单一指标，而是基于滑动窗口内的多维统计。以下是金融模型服务中常见的触发条件组合：
- 错误比例阈值： 最近 N 个请求中，错误（超时、5xx、业务异常）占比超过设定值（如 50%）。
- 最小请求数： 滑动窗口内请求总数必须达到一个最小值（如 10 个），避免在低流量下误触发。
- 慢调用比例： 响应时间超过设定阈值的请求占比过高（如 60% 的请求耗时 > 2 秒）。
- 连续失败计数： 部分实现支持基于连续失败次数（如连续 5 次失败）直接熔断。
实战建议： 在金融风控或定价模型中，建议将 错误比例阈值 与 最小请求数 组合使用。例如：最近 20 个请求中，错误率超过 40% 时触发熔断。这能有效过滤瞬时抖动，避免频繁状态切换。
3.4 熔断恢复策略
恢复策略决定了熔断器从 Open 状态回到正常服务的方式。核心在于 Half-Open 阶段的探测机制设计。
3.5 常见恢复策略对比
| 策略名称 | 核心机制 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|---|
| 固定超时恢复 | Open 状态持续固定时间（如 30 秒）后自动进入 Half-Open | 故障恢复时间相对稳定的场景 | 实现简单，易于理解 | 无法自适应故障持续时间 |
| 指数退避恢复 | 每次熔断超时时间递增（如 10s → 20s → 40s） | 故障可能持续较长时间的场景 | 减少对后端重复冲击 | 恢复延迟可能过长 |
| 自适应恢复 | 根据后端健康指标动态调整 Half-Open 时机 | 金融核心链路，需要快速恢复 | 恢复效率高，智能 | 实现复杂度高，依赖额外健康检测 |
3.6 关键配置参数速查
在实际编码中，熔断器通常暴露以下可配置参数。合理设置这些参数是保障金融模型服务稳定性的前提。
- failureRateThreshold： 失败率阈值，默认 50%。
- slowCallRateThreshold： 慢调用率阈值，默认 60%。
- slowCallDurationThreshold： 慢调用定义，如 2 秒。
- minimumNumberOfCalls： 滑动窗口最小请求数，默认 10。
- slidingWindowSize： 滑动窗口大小，默认 100 个请求。
- waitDurationInOpenState： Open 状态持续时间，默认 30 秒。
- permittedNumberOfCallsInHalfOpenState： Half-Open 允许探测请求数，默认 3。
避坑指南： 在金融模型服务中，minimumNumberOfCalls 不宜设置过小（如 1~2），否则在低流量时段，单次超时可能直接触发熔断，导致服务不可用。建议结合业务 QPS 设置，确保统计具有统计意义。
3.7 状态变更事件与监控
熔断器每次状态切换都应触发事件，供监控系统记录和告警。典型的事件类型包括：
- STATE_TRANSITION： 状态变更事件，记录 from → to 及原因。
- FAILURE_RATE_EXCEEDED： 失败率超阈值告警。
- SLOW_CALL_RATE_EXCEEDED： 慢调用率超阈值告警。
- NOT_PERMITTED： 请求被熔断器拒绝（Open 状态）的计数。
通过订阅这些事件，运维团队可以实时掌握熔断器行为，结合业务日志快速定位故障根因。