4. 熔断阈值设计原则：基于统计的阈值设定与业务容忍度分级

熔断阈值是API熔断机制的核心决策参数。阈值设定过松，熔断器形同虚设，模型服务持续降级仍被调用；阈值设定过严，正常流量波动也会触发熔断，导致可用性下降。本章从统计方法、业务容忍度、模型关键性三个维度，给出可落地的阈值设计原则。

4.1 基于统计的阈值设定方法

统计阈值需要解决两个核心问题：“什么是正常波动”和“什么是异常偏离”。滑动窗口、错误率、延迟百分位是三种最常用的统计基元。

4.1.1 滑动窗口（Sliding Window）

滑动窗口将时间轴划分为固定粒度的桶（bucket），每个桶独立统计请求量、错误数、延迟总和。窗口滑动时，旧桶被丢弃，新桶加入，保证统计数据的时效性。

4.1.2 错误率阈值（Error Rate Threshold）

错误率 = 窗口内错误请求数 / 窗口内总请求数 × 100%。错误类型包括HTTP 5xx、业务返回码异常、超时、连接拒绝等。

• 硬阈值：固定百分比，如错误率 > 50% 触发熔断。简单直接，但无法适应流量低谷期的小样本波动。
• 最小请求量保护：窗口内请求量低于N（如10次）时不触发熔断，避免冷启动误判。
• 渐进式阈值：错误率连续多个窗口超过基线（如3个窗口均 > 30%）才熔断，减少毛刺影响。

4.1.3 延迟百分位阈值（Latency Percentile Threshold）

延迟百分位比平均延迟更能反映尾部性能。P99延迟超过阈值，意味着1%的请求已经严重超时，模型服务可能正在退化。

4.2 业务容忍度与模型关键性分级

不同模型对业务的影响差异巨大。一个推荐模型的短暂降级可能只影响点击率，而一个风控模型的熔断可能直接导致交易阻断。因此，阈值必须与模型关键性分级挂钩。

4.2.1 模型关键性分级（Criticality Tier）

4.2.2 业务容忍度映射矩阵

将统计阈值与业务容忍度结合，形成最终的熔断决策矩阵。每个模型在部署时需明确其容忍度配置。

# 熔断阈值配置示例（YAML格式）
model_criticality:
  tier_0:
    window_size_sec: 60
    bucket_count: 12
    error_rate_threshold: 0.10        # 10% 错误率即熔断
    latency_p99_threshold_ms: 500
    min_request_count: 5
    consecutive_failures: 2           # 连续2个窗口触发即熔断
  tier_1:
    window_size_sec: 120
    bucket_count: 12
    error_rate_threshold: 0.30
    latency_p99_threshold_ms: 2000
    min_request_count: 10
    consecutive_failures: 3
  tier_2:
    window_size_sec: 300
    bucket_count: 15
    error_rate_threshold: 0.50
    latency_p99_threshold_ms: 5000
    min_request_count: 20
    consecutive_failures: 4
  tier_3:
    window_size_sec: 600
    bucket_count: 20
    error_rate_threshold: 0.80
    latency_p99_threshold_ms: 30000
    min_request_count: 50
    consecutive_failures: 5

4.3 阈值调优与持续校准

阈值不是一次性设定的静态值。模型上线后，流量模式、数据分布、模型版本都会变化，阈值需要持续校准。

• 基线采集：模型上线前7天，采集正常流量下的错误率、P50/P95/P99延迟，作为阈值基线。
• 动态基线：使用EWMA或Holt-Winters算法，自动学习时间序列的季节性模式，生成动态阈值。
• 灰度验证：新阈值先在10%流量上验证，观察误熔断率和漏熔断率，达标后再全量推广。
• 熔断事件复盘：每次熔断触发后，记录触发时的统计指标、窗口数据、业务影响，用于阈值修正。

4.4 本章小结