1. 限流与熔断概述
1.1 限流与熔断的定义
在分布式系统与微服务架构中，限流（Rate Limiting）与熔断（Circuit Breaking）是保障服务稳定性的两大核心手段。它们分别从流量入口与故障传播两个维度，防止系统被突发流量或级联故障击穿。
| 概念 | 定义 | 核心目标 | 典型触发条件 |
|---|---|---|---|
| 限流 | 对单位时间内的请求数量或速率进行限制，超过阈值的请求被拒绝或排队 | 保护后端资源不被过度消耗，维持服务吞吐与延迟的平衡 | QPS 超过预设阈值、并发数超过连接池上限 |
| 熔断 | 当下游服务或资源持续出现故障时，主动切断调用链路，快速返回降级响应 | 防止故障扩散，给下游恢复时间，避免雪崩效应 | 错误率超过阈值、超时比例过高、连续失败次数达到设定值 |
关键区别：限流是主动预防，在系统过载前就限制流量；熔断是被动防御，在检测到故障后切断链路。两者互补，共同构成微服务的韧性骨架。
1.2 在微服务中的重要性
微服务架构中，服务间依赖关系复杂，单个服务的抖动可能通过调用链放大为整个系统的故障。限流与熔断在以下场景中不可或缺：
- 防止热点打垮服务：秒杀、大促、爬虫攻击等突发流量，限流可确保核心服务不被冲垮。
- 阻断级联故障：服务 A 调用服务 B 超时，若不加熔断，A 的线程池会被快速耗尽，进而拖垮 A 的上游服务。
- 资源隔离与公平调度：多租户场景下，限流保证每个租户不会抢占全部资源。
- 降级与自愈：熔断后触发降级逻辑（如返回缓存数据），待下游恢复后自动闭合熔断器。
行业数据：据 Netflix 工程团队统计，引入熔断机制后，其微服务系统的平均故障恢复时间（MTTR）降低了 70% 以上，故障影响范围缩小了 90%。
1.3 Go 语言实现优势
Go 语言因其并发模型、编译效率与标准库支持，在实现限流熔断骨架时具备天然优势：
| 优势维度 | 具体体现 | 与限流熔断的关联 |
|---|---|---|
| 轻量级 Goroutine | 数十万并发协程，栈初始仅 2KB | 可轻松为每个请求或限流窗口创建独立协程，资源开销极低 |
| Channel 与 Select | 原生 CSP 通信模型，支持非阻塞收发 | 实现令牌桶、漏桶等限流算法时，channel 可做天然队列与信号量 |
| 标准库 time/rate | golang.org/x/time/rate 提供官方限流器 | 基于令牌桶算法，开箱即用，性能优异 |
| 编译为原生二进制 | 无虚拟机依赖，部署简单 | 限流熔断中间件可嵌入业务进程，无需额外代理 |
| 丰富的中间件生态 | go-kit、go-zero、kratos 等框架内置熔断器 | 可直接复用或定制成熟的熔断策略（如 Google SRE 算法） |
注意：虽然 Go 的并发模型降低了限流熔断的实现门槛，但分布式场景下仍需考虑原子性、一致性（如分布式计数器）和网络分区等问题。本课程后续章节将逐一深入这些边界。
1.4 限流与熔断的协作关系
下图展示了限流与熔断在微服务调用链中的典型协作位置：
1.5 典型实现架构
在 Go 项目中，限流与熔断通常以中间件形式嵌入 HTTP/gRPC 服务框架。以下是一个极简的限流中间件骨架：
// 基于令牌桶的限流中间件示例
import (
"net/http"
"golang.org/x/time/rate"
)
func RateLimitMiddleware(limiter *rate.Limiter) func(http.Handler) http.Handler {
return func(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if !limiter.Allow() {
http.Error(w, "429 Too Many Requests", http.StatusTooManyRequests)
return
}
next.ServeHTTP(w, r)
})
}
}