模块化熔断控制是将“失败判定—状态切换—逻辑路由—恢复探测”四步嵌入异步链路，实现可配置、可观测、可回滚的确定性熔断；主备模块须遵循统一输入/输出协议与错误分类；熔断器按业务粒度创建并绑定具体模块；半开状态按比例放行试探请求，结合成功率动态恢复；全流程可观测覆盖状态变更、备份指标与链路追踪因果链。
模块化熔断控制不是简单加个开关，而是把“失败判定—状态切换—逻辑路由—恢复探测”四步嵌入异步执行链路中，让超时后自动走备份逻辑成为可配置、可观测、可回滚的确定性行为。
明确主备模块的契约边界
主逻辑与备份逻辑必须遵循同一输入/输出协议，否则熔断触发后无法无缝接管。例如：
- 统一输入结构：都接收
{user_id: string, payload: any}，不因模块不同而改变字段名或嵌套层级 - 输出强约束：都返回
{status: 'success'|'fallback', data: any, source: 'primary'|'backup'}，便于上层做一致性处理 - 错误分类对齐：主模块抛出
TimeoutError，备份模块也需识别并透传同类错误，避免熔断器误判为新异常
在异步调用链中注入熔断器实例
不依赖全局单例，而是按业务场景粒度创建熔断器，绑定具体模块组合。以 PHP + ReactPHP 示例：
- 定义主模块调用封装：
PrimaryAPIClient::fetch()，内部使用AsyncClient并设timeout=8000 - 定义备份模块调用封装：
BackupAPIClient::fetch()，支持降级参数（如精简字段、缓存兜底） - 创建熔断器时指定 fallback 回调：
$circuitBreaker = new CircuitBreaker($primaryClient, $loop, [ 'failureThreshold' => 3, 'resetTimeout' => 60000, 'timeout' => 10000, 'fallback' => [$backupClient, 'fetch'] // 超时或连续失败时自动调用 ]);
利用半开状态实现渐进式恢复
熔断器进入半开状态后，并非全量切回主逻辑，而是按比例放行请求，同时监控成功率：
- 配置
halfOpenProbeRate = 0.2，即只允许 20% 请求试探主模块 - 若试探请求在 3 秒内成功且响应体完整，则状态切回 Closed；否则维持 Open 并延长重试间隔
- 备份逻辑在此期间持续提供服务，且其调用日志标记
source=fallback和triggered_by=circuit_open，便于归因分析
可观测性必须覆盖全流程断点
仅看“是否切换”不够，要能回答“为什么切”“切得对不对”“多久能切回来”：
- 记录每次状态变更时间戳、触发条件（如 “第3次超时达10s”）、当前请求数与失败数
- 对备份逻辑增加独立指标：
fallback_latency_p95、fallback_cache_hit_rate - 在链路追踪中将熔断决策点打标为 Span，关联主/备调用子 Span，形成完整因果链
