4. 熔断限流理论基础：熔断器模式与限流算法
在构建高可用分布式系统时，熔断与限流是保障服务稳定性的两大核心手段。熔断防止故障级联扩散，限流防止资源过载崩溃。本节将深入剖析熔断器模式（Circuit Breaker Pattern）与三种主流限流算法（令牌桶、漏桶、滑动窗口），为后续 Terraform 自动化部署打下坚实的理论基础。
4.1 熔断器模式（Circuit Breaker Pattern）
熔断器模式源自电路工程中的断路器概念。在分布式系统中，当某个下游服务持续出现故障或超时，熔断器会“断开”对该服务的调用，快速返回降级响应，避免调用方线程被长时间阻塞，从而保护整个系统的可用性。
4.1.1 熔断器的三种状态
| 状态 | 说明 | 行为 |
|---|---|---|
| CLOSED（关闭） | 正常状态，请求直接通过 | 统计失败率，当失败率超过阈值（如 50%）且请求量达到最小计数时，触发状态转换 |
| OPEN（打开） | 熔断状态，请求被快速拒绝 | 直接返回降级响应（如 fallback 数据），不发起真实调用；经过超时时间后进入 HALF_OPEN |
| HALF_OPEN（半开） | 试探状态，允许少量请求通过 | 若试探请求成功，则重置为 CLOSED；若失败，则回到 OPEN 并重置超时计时器 |
关键参数：熔断器通常需要配置
failureThreshold（失败阈值）、successThreshold（成功阈值）、timeout（打开到半开的等待时间）以及 minimumNumberOfCalls（最小请求基数）。这些参数直接影响熔断的灵敏度和恢复速度。
4.1.2 熔断器状态转换流程
下图展示了熔断器在三种状态之间的转换逻辑，以及每个状态下的核心决策点。
4.1.3 熔断器在微服务中的典型应用
- 服务间调用保护：当依赖的支付服务、库存服务出现故障时，熔断器快速降级，避免调用方线程池耗尽。
- 数据库/缓存访问：当 Redis 或数据库响应超时，熔断器可防止大量请求压垮后端存储。
- 第三方 API 集成：对不可控的外部服务（如短信、地图 API）启用熔断，提升系统韧性。
避坑提示：熔断器的超时时间不宜设置过短，否则在短暂抖动时频繁触发熔断，反而降低可用性。建议结合历史 P99 延迟数据来设定 timeout 值。
4.2 限流算法
限流（Rate Limiting）用于控制单位时间内请求的通过数量，防止突发流量冲垮系统。常见的限流算法包括令牌桶、漏桶和滑动窗口，各有适用场景。
4.2.1 令牌桶算法（ Bucket）
令牌桶以固定速率向桶中添加令牌，每个请求需要消耗一个令牌才能被处理。桶有容量上限，允许一定程度的突发流量。
| 特性 | 说明 |
|---|---|
| 核心参数 | rate（令牌生成速率，如 100 个/秒）、capacity（桶容量，如 200） |
| 突发能力 | 支持突发流量：桶内积攒的令牌可被一次性消耗，最大突发量 = capacity |
| 适用场景 | 允许短时突发的 API 网关、消息推送、视频流服务 |
| 实现复杂度 | 低，通常使用定时器或延迟计算实现 |
4.2.2 漏桶算法（Leaky Bucket）
漏桶将请求放入一个固定容量的队列（桶），然后以恒定速率从桶底“漏出”请求进行处理。桶满时新请求被丢弃。
| 特性 | 说明 |
|---|---|
| 核心参数 | capacity（桶容量，即队列长度）、leakRate（漏出速率，如 50 个/秒） |
| 突发能力 | 不支持突发：无论入口流量多大，出口速率恒定 |
| 适用场景 | 需要平滑流量的场景，如数据库写入、日志收集、消息队列消费 |
| 实现复杂度 | 中，需要维护队列或计数器 |
4.2.3 滑动窗口算法（Sliding Window）
滑动窗口将时间划分为多个小窗口（如 1 秒），统计当前时间点所在窗口及之前 N 个窗口内的请求总数。当总数超过阈值时拒绝新请求。
| 特性 | 说明 |
|---|---|
| 核心参数 | windowSize（窗口总时长，如 10 秒）、threshold（窗口内最大请求数）、bucketCount（子窗口数量） |
| 突发能力 | 有限突发：子窗口越细，突发控制越精确 |
| 适用场景 | 需要精确控制速率且对突发敏感的接口，如登录、下单、秒杀 |
| 实现复杂度 | 中高，需要维护环形数组或时间轮 |
4.2.4 三种限流算法对比
| 维度 | 令牌桶 | 漏桶 | 滑动窗口 |
|---|---|---|---|
| 突发支持 | ✅ 支持（积攒令牌） | ❌ 不支持 | ⚠️ 有限支持（取决于子窗口粒度） |
| 平滑度 | 中等（允许突发后平滑） | 高（恒定速率） | 中等（窗口边界可能有抖动） |
| 实现难度 | 低 | 中 | 中高 |
| 内存开销 | 低（仅维护计数器） | 中（需要队列） | 中高（需要维护多个子窗口计数） |
| 典型框架 | Guava RateLimiter, Sentinel | Nginx limit_req, Kong | Sentinel 滑动窗口, Redis + Lua |
选型建议：在 Terraform 自动化部署中，我们通常为 API 网关选择令牌桶（允许突发流量），为数据库连接池选择漏桶（平滑写入），为关键业务接口选择滑动窗口（精确控制）。后续章节将演示如何通过 Terraform 配置这些限流策略。
4.3 熔断与限流的协同关系
熔断和限流并非互斥，而是互补的防护手段：
- 限流作用于入口，防止流量超过系统承载上限。
- 熔断作用于出口（下游依赖），防止故障扩散。
- 两者结合形成“入口限流 + 出口熔断”的双层防护，是生产环境高可用架构的标准配置。
下图展示了熔断与限流在微服务调用链中的协同位置。
4.4 本章小结
- 熔断器模式通过 CLOSED → OPEN → HALF_OPEN 三态转换，保护系统免受下游故障影响。
- 令牌桶支持突发，适合 API 网关；漏桶平滑流量，适合数据库写入；滑动窗口精确控制，适合关键业务。
- 在生产架构中，入口限流 + 出口熔断是标准组合，Terraform 可将其自动化部署为 IaC 配置。
下节预告：我们将进入实战环节，使用 Terraform 在 AWS/Azure 上部署一个包含熔断器和令牌桶限流的微服务网关，并编写完整的 Terraform 配置代码。