1. 限流熔断概述：金融API面临的流量冲击、雪崩效应、限流与熔断的核心区别、课程目标与学习路径
1.1 金融API面临的流量冲击
金融核心API（如交易下单、账户查询、风控校验）在特定业务场景下会遭遇突发流量冲击，导致系统过载甚至崩溃。常见的流量冲击来源包括：
- 行情异动：重大政策发布、财报披露、市场剧烈波动引发瞬间海量交易请求。
- 营销活动：秒杀、红包、理财抢购等运营活动带来数十倍于日常的并发峰值。
- 外部攻击：DDoS攻击、恶意刷接口、爬虫抓取数据等非正常流量。
- 上下游级联：上游系统（如行情推送）故障导致下游重试风暴，流量层层放大。
关键数据：某头部券商在2023年“双十一”理财节期间，交易API峰值QPS达到日常的 47倍，若未配置限流策略，核心网关将在30秒内完全不可用。
1.2 雪崩效应：从单点故障到全局瘫痪
雪崩效应是分布式金融系统中最为致命的连锁故障模式。其典型传导路径如下：
- 单点过载：某个下游服务（如风控引擎）因流量冲击响应变慢。
- 请求堆积：上游调用方等待超时，线程/连接资源被持续占用。
- 资源耗尽：上游系统的线程池、数据库连接池、内存被耗尽。
- 故障扩散：上游系统自身也变为不可用，影响更多依赖它的服务。
- 全局瘫痪：故障沿调用链向上游和旁路扩散，最终导致整个业务域不可用。
金融级警示：2020年某银行核心账务系统因一个非关键查询接口的慢SQL引发雪崩，最终导致全行柜面交易中断47分钟，直接经济损失超千万元。限流与熔断是阻断雪崩的最后一道防线。
1.3 限流与熔断的核心区别
限流（Rate Limiting）和熔断（Circuit Breaking）是两种不同维度的保护机制，常被混淆。下表从多个维度进行清晰对比：
| 对比维度 | 限流（Rate Limiting） | 熔断（Circuit Breaking） |
|---|---|---|
| 核心目标 | 控制请求速率，防止系统过载 | 快速失败，防止故障扩散 |
| 触发条件 | 请求速率超过预设阈值（QPS/TPS） | 错误率/超时率超过阈值（如50%错误） |
| 作用位置 | 通常部署在网关或入口层 | 通常部署在服务调用链的客户端侧 |
| 处理动作 | 直接拒绝、排队等待、流量整形 | 快速返回降级响应，停止调用下游 |
| 恢复机制 | 流量下降后自动恢复 | 半开探测，确认下游恢复后关闭熔断 |
| 关注指标 | 请求速率、并发数 | 错误率、超时率、慢调用比例 |
| 典型场景 | 秒杀、API配额管理 | 依赖服务故障、网络分区 |
实践原则：限流是“预防性”保护，熔断是“反应性”保护。在金融系统中，两者必须组合使用——限流控制入口流量，熔断阻断级联故障，缺一不可。
1.4 限流与熔断的协同关系（SVG架构图）
下图展示了限流与熔断在金融API调用链中的协同工作位置与数据流：
1.5 课程目标与学习路径
本课程旨在帮助金融系统架构师、SRE工程师和高级开发人员，系统掌握从开发到运维全流程的限流熔断实战能力。课程目标分为三个层级：
| 层级 | 目标 | 核心产出 |
|---|---|---|
| L1：原理层 | 深入理解限流算法（令牌桶、漏桶、滑动窗口）与熔断状态机（关闭/打开/半开） | 能根据业务场景选择正确的限流熔断策略 |
| L2：开发层 | 掌握在Python/Go中实现限流熔断组件，集成到金融API网关和微服务中 | 可独立开发生产级限流熔断中间件 |
| L3：运维层 | 配置监控告警、动态调整阈值、演练故障注入、分析限流熔断日志 | 构建可观测、可自愈的金融API韧性体系 |
1.6 推荐学习路径（SVG流程图）
学习建议：建议按照“原理 → 开发 → 运维”的顺序循序渐进。每章均配有可运行的代码示例和故障演练场景，请务必在本地或云环境动手实践。金融系统对稳定性要求极高，切勿在生产环境直接使用未经压测的限流熔断配置。