1. 课程导论与金融API背景
1.1 为什么金融API需要限流与熔断
金融系统对API的依赖已从简单的数据查询演变为核心交易链路的关键环节。一个典型的证券交易API网关，每秒需要处理数万笔订单查询、行情推送和资金划转请求。当突发流量、上游服务故障或恶意攻击发生时，缺乏保护机制的API会迅速引发级联故障，导致整个交易系统不可用。
金融API面临的三大核心风险：
- 流量洪峰：开盘/收盘时段、重大行情波动、新股申购等场景，瞬时请求量可达正常值的10-50倍。
- 依赖雪崩：一个下游服务（如风控引擎）响应变慢，导致上游API线程池耗尽，最终拖垮整个网关。
- 资源耗尽：数据库连接池、内存、CPU被异常请求占满，正常交易请求被拒绝。
限流（Rate Limiting）与熔断（Circuit Breaker）正是应对上述风险的两大核心手段。限流通过控制单位时间内的请求量来保护后端资源；熔断则在依赖故障达到阈值时快速切断调用链路，防止故障扩散。
| 保护机制 | 核心目标 | 典型触发条件 | 恢复策略 |
|---|---|---|---|
| 限流 | 控制请求速率，保护自身资源 | QPS/TPS超过阈值、并发数超限 | 滑动窗口重置、令牌桶补充 |
| 熔断 | 快速失败，防止级联故障 | 错误率/超时率超过阈值 | 半开探测、健康检查恢复 |
| 降级 | 提供有损服务，保证核心功能 | 熔断触发、资源不足 | 返回兜底数据、异步处理 |
行业参考： 某头部券商在2023年行情剧烈波动期间，因未配置限流策略，导致行情API被高频查询打满，交易下单接口响应时间从5ms飙升至12s，最终触发交易所风控暂停其交易权限。事后复盘，仅需在网关层配置基于令牌桶的限流即可避免该事故。
1.2 课程目标与学习路径
本课程旨在帮助金融系统架构师和Python高级工程师，从零搭建一套生产可用的API限流熔断框架。课程不局限于理论讲解，而是通过完整的代码实现、单元测试和压测验证，确保学员能够将所学直接应用于实际项目。
课程三大目标：
- 掌握核心算法：深入理解令牌桶、漏桶、滑动窗口、自适应限流等算法的原理与Python实现。
- 构建生产级框架：基于asyncio实现高性能限流器与熔断器，支持配置热加载、指标采集、告警集成。
- 完成全链路测试：使用pytest+locust进行单元测试、集成测试和压力测试，验证框架在极端场景下的表现。
| 阶段 | 章节范围 | 核心产出 | 难度 |
|---|---|---|---|
| 基础篇 | 第1-5章 | 限流算法实现、熔断器状态机 | ★★☆ |
| 框架篇 | 第6-12章 | 异步框架搭建、配置中心、指标采集 | ★★★ |
| 集成篇 | 第13-20章 | FastAPI/Flask集成、Redis分布式限流 | ★★★☆ |
| 测试篇 | 第21-26章 | 单元测试、压测、混沌工程 | ★★★★ |
| 实战篇 | 第27-30章 | 生产部署、监控告警、案例复盘 | ★★★★ |
前置要求： 学员需具备Python 3.9+基础、熟悉asyncio基本用法、了解HTTP协议和RESTful API设计。建议先完成《Python异步编程实战》或同等课程。
1.3 金融系统高可用设计原则
金融系统的高可用设计遵循一套经过行业验证的架构原则。这些原则直接指导限流熔断框架的设计决策，是课程后续章节反复引用的理论基础。
在限流熔断框架的设计中，以下原则具有直接指导意义：
- 快速失败优于慢速失败：当检测到下游故障时，熔断器应迅速返回错误，而不是让请求排队等待超时。这能避免线程/协程资源被无效占用。
- 有损服务优于完全不可用：限流触发时，返回友好的降级响应（如“系统繁忙，请稍后重试”），而不是直接断开连接。核心交易链路应优先保障。
- 防御性编程：限流熔断框架本身不能成为单点故障。框架应具备自我保护和降级能力，例如当限流器自身出现异常时，应默认放行请求（fail-open）或快速失败（fail-fast）。
- 数据一致性优先：在熔断恢复阶段，半开探测请求必须确保数据一致性校验通过后，才能关闭熔断器。金融场景下，不允许出现“服务恢复但数据不一致”的状态。
常见误区： 部分团队将限流阈值设置过高，认为“预留足够余量”即可。实际上，限流的核心价值在于保护系统在极端情况下的稳定性，而非追求最大吞吐。建议基于压测结果设置阈值，并预留30%-50%的缓冲空间。