2. 核心概念：限流与熔断
在金融压力测试场景下，模型服务（Model Serving）需要同时应对突发流量洪峰与后端依赖故障。限流（Rate Limiting）与熔断（Circuit Breaker）是保障服务稳定性的两大核心手段，二者目标互补但机制不同。
2.1 限流（Rate Limiting）定义
限流是一种主动防御策略，通过控制单位时间内进入系统的请求数量，防止上游流量超过服务处理能力的阈值。在金融压力测试中，限流确保模型推理服务不会因瞬间高并发而耗尽 CPU/GPU 或内存资源。
- 控制粒度：QPS（每秒查询数）、TPM（每分钟事务数）、并发连接数。
- 常见算法：令牌桶（Token Bucket）、漏桶（Leaky Bucket）、滑动窗口（Sliding Window）。
- 触发动作：直接拒绝（返回 429 Too Many Requests）、排队等待、降级返回缓存结果。
- 金融场景示例：某风控模型服务设定单机 QPS 上限为 2000，超过部分直接拒绝，避免模型推理队列堆积导致整体延迟飙升。
关键指标：限流阈值通常基于压力测试结果设定，一般取服务 P99 延迟可接受范围内的最大吞吐量的 80%。
2.2 熔断（Circuit Breaker）定义
熔断是一种被动恢复策略，当检测到下游依赖（如数据库、第三方模型 API）持续故障或响应超时时，快速切断调用链路，防止故障级联扩散。熔断器状态机包含三个状态：关闭（Closed）、打开（Open）、半开（Half-Open）。
- 关闭状态：正常调用，统计错误率或超时比例。
- 打开状态：错误率超过阈值（如 50%），直接快速失败，不发起真实调用。
- 半开状态：经过冷却时间后，允许少量探测请求通过，判断下游是否恢复。
- 金融场景示例：模型服务依赖的标签数据库响应超时率超过 30%，熔断器打开，后续请求直接返回降级结果，避免线程池耗尽。
注意：熔断不能替代超时设置。必须为每个下游调用配置合理的超时时间（如 500ms），否则熔断器可能因长时间挂起线程而失效。
2.3 两者区别与联系
限流和熔断虽然都用于保护系统，但关注点与作用位置不同。下表从多个维度进行对比：
| 对比维度 | 限流（Rate Limiting） | 熔断（Circuit Breaker） |
|---|---|---|
| 保护方向 | 上游 → 本服务（入口防御） | 本服务 → 下游（出口防御） |
| 触发条件 | 请求速率超过预设阈值 | 下游错误率/超时率超过阈值 |
| 状态模型 | 连续计数（窗口/桶） | 三态机（关闭/打开/半开） |
| 恢复方式 | 窗口滑动后自动恢复 | 冷却时间后探测恢复 |
| 典型响应 | 429 Too Many Requests | 503 Service Unavailable |
| 金融压力测试作用 | 防止模型推理过载 | 防止依赖故障扩散 |
联系与协同：
- 两者常组合使用：限流保护本服务不被压垮，熔断保护本服务不因下游故障而拖垮。
- 在金融压力测试中，限流阈值和熔断参数需通过混沌工程实验联合调优。例如，先通过限流控制入口流量为正常峰值的 1.5 倍，再设置熔断器在错误率 40% 时打开。
- 典型部署模式：API 网关层做限流，服务调用层做熔断，形成双层防护。
实践建议：在金融压力测试脚本中，同时注入限流和熔断配置。例如，使用 Sentinel 或 Hystrix 组件，限流阈值设为压测最大 QPS 的 1.2 倍，熔断错误率阈值设为 40%，冷却时间 10 秒。通过逐步加压验证双层防护的有效性。