1. 金融压力测试概述
1.1 金融系统压力测试的定义
金融压力测试是一种定量风险分析工具，通过模拟极端但合理的市场情景（如利率骤升、汇率暴跌、交易量突增等），评估金融系统或单个机构在极端冲击下的资本充足性、流动性及业务连续性。在 API 网关层面，压力测试特指对网关的吞吐量、并发连接数、响应延迟及熔断恢复能力进行极限验证。
核心目标：识别系统在极端负载下的瓶颈与脆弱点，确保核心交易链路不因突发流量而中断。
1.2 压力测试的目的
- 验证容量上限：确定 API 网关在 CPU、内存、网络带宽等资源约束下的最大承载 TPS（每秒事务数）。
- 评估弹性能力：检验限流、熔断、降级、重试等容错机制在真实压力下的触发阈值与恢复行为。
- 满足监管合规：向监管机构证明系统具备抵御极端市场冲击的能力（如巴塞尔协议 III 对操作风险资本计量的要求）。
- 保障业务连续性：确保核心交易、账户查询、风控校验等关键 API 在压力下仍能提供可接受的响应质量。
1.3 监管要求：巴塞尔协议 III 的启示
| 监管维度 | 巴塞尔协议 III 要求 | API 网关层面的映射 |
|---|---|---|
| 操作风险资本计量 | 要求银行基于历史损失与情景分析计提操作风险资本 | 网关需记录限流熔断事件日志，作为操作风险损失数据集的输入 |
| 流动性覆盖率 (LCR) | 确保优质流动性资产足以应对 30 天压力情景下的净现金流出 | 网关需对高频查询类 API 实施差异化限流，防止非核心流量挤占流动性查询通道 |
| 杠杆率监管 | 限制银行表内外杠杆暴露，防止过度扩张 | 网关需对第三方合作机构 API 调用设置配额上限，避免单一渠道过度占用 |
| 压力测试频率 | 至少每年一次全面压力测试，高风险机构需更频繁 | 网关限流熔断策略需随压力测试结果定期调优，并纳入混沌工程演练 |
实践要点：国内金融监管机构（如中国人民银行、银保监会）在《商业银行压力测试指引》中明确要求将操作风险纳入压力情景。API 网关作为交易入口，其限流熔断日志已成为操作风险数据采集的关键来源。
1.4 API 网关层面压力测试的重要性
API 网关是金融系统的统一流量入口，承载着认证鉴权、路由转发、协议转换、限流熔断等核心职能。在压力测试中，网关层具有以下不可替代的地位：
- 第一道防线：网关是流量进入后端微服务集群前的最后一道屏障，其限流熔断策略直接决定后端能否存活。
- 全局视角：网关可观测所有 API 的调用模式，便于制定全局性的分级限流策略（如核心交易 API 优先级高于日志查询 API）。
- 快速迭代：网关策略支持热更新，压力测试中发现的阈值偏差可立即调整，无需重启后端服务。
- 故障隔离：通过熔断机制，网关能快速切断对异常后端的请求，防止雪崩效应扩散。
1.5 压力测试的关键指标
| 指标 | 定义 | 金融场景典型阈值 |
|---|---|---|
| TPS（每秒事务数） | 网关每秒成功处理的完整请求数 | 核心交易 ≥ 2000 TPS；查询类 ≥ 10000 TPS |
| P99 延迟 | 99% 的请求在多少毫秒内完成 | 交易 API ≤ 300ms；查询 API ≤ 100ms |
| 错误率 | 返回 5xx 或超时的请求占比 | 压力测试期间 ≤ 1%（熔断触发前） |
| 熔断恢复时间 | 从熔断打开到半开再到完全关闭的时间 | ≤ 30s（金融行业要求快速自愈） |
| 资源饱和度 | CPU / 内存 / 网络带宽使用率 | CPU ≤ 80%，内存 ≤ 75% |
常见误区：仅关注 TPS 而忽略 P99 延迟。在金融场景中，即使平均延迟正常，P99 延迟的突增也可能导致交易超时回滚，造成资金差错。压力测试必须同时关注延迟分布。
1.6 压力测试与限流熔断的关系
压力测试为限流熔断策略提供数据基准，限流熔断则是压力测试落地的执行手段。二者形成闭环：
- 测试 → 发现阈值：通过逐步加压，找到网关的极限 TPS 和延迟拐点。
- 阈值 → 配置策略：将拐点值下调 20%~30% 作为限流熔断的触发阈值（安全余量）。
- 策略 → 验证效果：再次执行压力测试，验证限流熔断是否按预期保护后端。
- 效果 → 持续调优：根据生产环境的实际流量模式，定期调整阈值并回归测试。