3. API熔断机制基础
3.1 熔断的定义
熔断（Circuit Breaker）是一种自我保护机制，当被调用的下游服务（如催收渠道API、第三方数据源）持续出现故障、超时或异常时，主动切断调用链路，避免故障蔓延到整个系统。熔断器在金融科技催收系统中扮演“安全阀”角色，防止因单一渠道崩溃导致催收引擎雪崩。
核心思想： 快速失败（Fail Fast） + 自我恢复（Self-healing）。熔断器在检测到错误率达到阈值后，直接拒绝请求，而不是让请求继续等待或重试，从而保护系统资源。
3.2 熔断与限流/降级的区别
在催收API治理中，熔断、限流、降级是三个容易混淆的概念，但它们解决的问题和触发机制完全不同。下表从多个维度进行对比：
| 对比维度 | 熔断 (Circuit Breaker) | 限流 (Rate Limiting) | 降级 (Degradation) |
|---|---|---|---|
| 核心目标 | 防止故障扩散，保护调用方 | 控制流量速率，保护被调用方 | 牺牲非核心功能，保障核心功能 |
| 触发条件 | 下游错误率/超时率超过阈值 | 请求速率超过预设QPS/TPS | 系统资源不足或人工预案 |
| 作用范围 | 针对特定下游服务或渠道 | 针对API端点或用户/IP维度 | 针对业务功能模块 |
| 恢复方式 | 自动半开试探，成功后关闭 | 窗口期过后自动恢复 | 通常需要人工或定时恢复 |
| 催收场景示例 | 某催收渠道连续5分钟超时率>50%，熔断该渠道 | 催收请求峰值超过渠道QPS限制，排队或拒绝 | 催收系统负载过高，关闭短信通知，仅保留电话催收 |
记忆口诀： 熔断是“下游坏了我不调”，限流是“调太多了我挡一挡”，降级是“功能太多我先砍一部分”。
3.3 熔断在催收场景中的必要性
催收系统对API的依赖程度极高，且具有明显的业务特殊性。如果没有熔断机制，以下风险将直接威胁系统稳定性：
- 渠道雪崩风险： 当某个催收渠道（如某家外呼供应商）出现故障时，大量请求堆积在等待队列中，占用线程池和连接池资源，最终拖垮整个催收引擎。
- 级联故障传导： 催收流程通常串联多个API（如身份核验→号码查询→外呼→录音上传），一个环节的故障会阻塞后续所有环节。
- 成本失控： 部分催收渠道按调用次数计费。在渠道故障期间，无意义的重复调用不仅浪费资金，还会被渠道方标记为恶意流量。
- 监管合规风险： 催收行为受严格监管，API异常可能导致重复催收、错误催收，引发客户投诉和监管处罚。
催收场景特别警示： 催收API的熔断阈值设置不能照搬通用互联网服务。催收渠道的“错误”需要区分是技术故障（如HTTP 500）还是业务拒绝（如号码已停机）。后者属于正常业务反馈，不应触发熔断。建议将业务错误码和技术错误码分开统计，仅对技术类错误进行熔断计数。
3.4 催收场景熔断的关键参数
在实际配置催收API熔断器时，以下三个参数需要根据渠道特性进行调优：
| 参数名称 | 默认推荐值 | 催收场景调优建议 |
|---|---|---|
| 错误率阈值 | 50% | 对于高可用渠道（如运营商网关），建议设为30%；对于备用渠道，可放宽至70% |
| 最小请求数 | 10次 | 催收低频渠道（如每日仅几百次调用）建议设为5次，避免统计样本不足 |
| 熔断超时窗口 | 30秒 | 催收渠道故障恢复通常较慢，建议设为60~120秒，避免频繁开关导致抖动 |
最佳实践： 在催收系统中，建议为每个渠道独立配置熔断器，并支持动态调整参数。当渠道方发布维护公告时，运维人员可提前手动熔断该渠道，避免大量请求积压。