1. 课程导论：金融压力测试背景、模型服务面临的挑战、限流熔断的必要性
1.1 金融压力测试背景
金融压力测试是金融机构评估极端市场条件下自身资本充足性与风险承受能力的核心工具。自2008年全球金融危机后，巴塞尔协议III及各国监管机构（如美联储CCAR、欧洲EBA）将压力测试纳入常态化监管框架。其核心目标是在假设的“尾部风险”场景下，验证银行、保险、券商等机构的资产质量、流动性及资本缓冲是否达标。
现代压力测试已从传统的批量计算模式演进为实时/准实时模型服务架构。业务部门需要在分钟级甚至秒级内获取数千个风险因子冲击下的损益结果，以支持快速决策。这要求底层模型服务具备高吞吐、低延迟、高可用的能力。
关键趋势： 压力测试正从“年度合规演练”转向“日常风险管理工具”，模型调用频率从季度级提升至分钟级，对基础设施的弹性与稳定性提出严峻挑战。
1.2 模型服务面临的挑战
在金融压力测试场景中，模型服务（Model Serving）通常承载着定价模型、风险计量模型、机器学习违约预测模型等核心逻辑。当压力测试并发启动时，系统会面临以下四大核心挑战：
| 挑战维度 | 具体表现 | 典型后果 |
|---|---|---|
| 流量洪峰 | 压力测试启动瞬间，数千个场景并行请求涌入，QPS 可飙升至正常值的 50~100 倍 | 模型实例 CPU/GPU 满载，请求排队超时，整体吞吐骤降 |
| 资源竞争 | 多个模型共享 GPU 显存或 CPU 核数，高并发下出现显存溢出（OOM）或线程死锁 | 模型加载失败，服务进程被 OOM Killer 杀死，影响其他业务 |
| 长尾延迟 | 部分复杂模型（如蒙特卡洛模拟）单次推理耗时可达秒级，拖慢整体响应 | 上游业务超时重试，引发请求雪崩，最终导致服务级联崩溃 |
| 依赖脆弱性 | 模型服务依赖数据库、缓存、消息队列等中间件，任一组件故障都会传导 | 数据库连接池耗尽，模型服务无响应，压力测试任务失败 |
这些挑战在金融场景中被进一步放大：数据一致性要求高（不能丢弃请求）、监管审计严格（需记录每次调用的入参和结果）、业务连续性要求高（SLA 通常要求 99.99% 可用率）。
1.3 限流熔断的必要性
面对上述挑战，传统的“垂直扩容”或“水平扩容”无法完全解决问题：扩容存在延迟，且成本高昂；而压力测试的流量往往是突发性的，峰值过后资源闲置。因此，必须引入限流（Rate Limiting）与熔断（Circuit Breaking）机制，作为模型服务的第一道防线。
限流的核心作用
- 保护后端资源： 控制单位时间内进入模型服务的请求量，防止 CPU/GPU 过载，确保服务稳定运行。
- 公平调度： 在多个业务方（如交易台、风控部、合规部）共享同一模型服务时，按权重分配配额，避免某个业务方“饿死”其他方。
- 削峰填谷： 将超出阈值的请求排队或降级，平滑流量曲线，避免系统被瞬时洪峰冲垮。
熔断的核心作用
- 快速失败： 当模型服务或下游依赖出现连续错误（如超时、500 错误）时，熔断器打开，直接拒绝请求，防止故障蔓延。
- 自动恢复： 熔断器在半开状态下探测服务是否恢复，恢复后自动关闭，减少人工介入。
- 隔离故障： 将故障模型实例隔离，避免单个模型的问题影响整个模型服务集群。
金融场景的特殊要求： 限流熔断不能简单丢弃请求。对于压力测试这种“必须完成”的任务，需要配合请求排队、降级返回默认值、异步回填等策略，确保最终一致性。
1.4 限流熔断在金融场景中的特殊考量
与互联网场景不同，金融压力测试中的限流熔断不能简单“丢弃请求”。以下是需要特别关注的几个方面：
| 场景 | 互联网通用做法 | 金融压力测试要求 |
|---|---|---|
| 请求超限 | 直接返回 429 Too Many Requests | 请求入队等待，或返回最近一次缓存结果，确保不丢失 |
| 服务熔断 | 快速失败，客户端重试其他节点 | 记录熔断事件，触发告警，同时启动备用模型实例 |
| 降级策略 | 返回空数据或默认值 | 返回保守估计值（如压力测试场景下的最低资本要求），并标记数据质量 |
| 审计追踪 | 通常不记录限流日志 | 所有限流、熔断、降级操作必须记录完整日志，供监管审查 |
注意： 在金融压力测试中，限流熔断方案的设计必须与业务团队充分沟通。例如，某些监管场景要求“必须完成全部计算”，此时限流只能作为保护手段，不能作为跳过计算的借口。需要配合异步计算、结果回填等机制来保证最终完整性。