1. 金融系统高可用挑战：雪崩效应与级联故障的成因分析
1.1 金融交易场景对 API 可用性的苛刻要求
金融交易系统对 API 可用性的要求远高于普通互联网应用。一笔失败的交易可能直接导致资金损失、监管处罚和品牌声誉受损。以下是金融场景中 API 可用性的核心指标与行业基准：
| 指标 | 行业基准 | 金融场景要求 | 说明 |
|---|---|---|---|
| 可用性 (SLA) | 99.9% (3个9) | 99.99% ~ 99.999% (4~5个9) | 年停机时间不超过 5.26 分钟 |
| P99 延迟 | < 500ms | < 50ms (核心交易) | 高频交易场景要求 < 1ms |
| 错误率 | < 1% | < 0.01% | 非业务拒绝的 HTTP 5xx 错误 |
| 并发吞吐 | 万级 QPS | 十万 ~ 百万级 QPS | 秒杀、行情推送等峰值场景 |
关键认知： 金融 API 的可用性不是"尽力而为"，而是"必须达成"。一个 99.99% 可用性的系统，在一年中仍有约 52 分钟的不可用时间。对于每秒处理数万笔交易的系统，这 52 分钟可能意味着数亿资金的损失。
1.2 雪崩效应：从单点故障到系统瘫痪
雪崩效应（Cascading Failure）是指系统中某个微小的局部故障，通过服务间的依赖关系被不断放大，最终导致整个系统大面积不可用的现象。在金融微服务架构中，这种效应尤为致命。
真实案例： 某券商在 2020 年行情火爆时，行情推送服务因流量激增导致响应变慢。依赖该服务的交易下单服务因等待行情数据而阻塞线程池，最终导致整个交易链路瘫痪，影响数十万投资者。
雪崩效应的典型传播路径如下：
- 触发点： 某个上游服务（如行情推送）因流量突增、硬件故障或代码缺陷而响应变慢。
- 资源耗尽： 下游服务（如交易下单）调用上游时，线程被阻塞等待响应，线程池迅速耗尽。
- 连锁反应： 下游服务自身也开始拒绝新请求，错误向上游传播，影响更多依赖方。
- 系统瘫痪： 整个调用链路中的服务全部进入不可用状态，形成"雪崩"。
1.3 级联故障的深层成因分析
级联故障并非偶然发生，其背后存在一系列系统性的设计缺陷。理解这些成因是构建高可用架构的前提。
| 成因类别 | 具体表现 | 金融场景典型问题 |
|---|---|---|
| 资源耦合 | 共享线程池、连接池、数据库连接 | 交易服务与行情服务共用线程池，行情拥堵拖垮交易 |
| 同步阻塞 | 同步 HTTP/RPC 调用，等待超时 | 下单服务同步等待风控校验结果，风控变慢则下单阻塞 |
| 缺乏隔离 | 所有接口共享资源，无优先级区分 | 查询接口与下单接口混跑，查询流量挤占下单资源 |
| 重试风暴 | 客户端无限制重试，放大流量 | 支付超时后客户端每秒重试一次，瞬间打爆后端 |
| 缓存穿透 | 热点 Key 失效，请求直达数据库 | 股票行情缓存失效，所有客户端同时查询数据库 |
避坑指南： 很多团队在故障复盘时只关注"哪个服务挂了"，而忽略了"为什么挂了之后其他服务也跟着挂了"。级联故障的核心问题不是单点故障本身，而是故障传播的路径没有被切断。
1.4 金融场景特有的高可用挑战
除了通用技术问题，金融系统还面临以下特有的高可用挑战：
- 监管合规要求： 交易日志必须完整持久化，不可丢、不可篡改，这增加了系统的 I/O 压力。
- 资金安全约束： 不允许"最终一致性"的宽松保证，必须强一致性，导致分布式事务复杂度剧增。
- 行情峰值冲击： 开盘、收盘、重大事件发布时，流量可在数秒内飙升 10~100 倍。
- 多活部署复杂性： 同城双活、异地多活架构下，跨机房调用延迟和网络分区风险显著增加。
1.5 从挑战到解决方案：限流与熔断的定位
面对上述挑战，限流（Rate Limiting）和熔断（Circuit Breaking）是切断故障传播路径、保障系统稳定性的核心手段：
- 限流：主动控制进入系统的请求速率，防止流量超过系统承载能力，从源头避免资源耗尽。
- 熔断：被动检测下游服务的健康状态，当下游故障率达到阈值时自动切断调用，防止故障向上游蔓延。