1. 限流与熔断概述
1.1 什么是限流
限流（Rate Limiting / Throttling）是一种通过控制单位时间内允许通过的请求数量，来保护系统不被突发流量冲垮的防护手段。在 Go 微服务中，限流通常作用于网关、API 端点或核心业务逻辑的入口处。
限流的本质是主动拒绝超出阈值的请求，让系统始终运行在安全负载范围内。常见的限流算法包括：
| 算法 | 核心思想 | 典型场景 |
|---|---|---|
| 计数器（固定窗口） | 将时间划分为固定窗口，每个窗口内计数，超限则拒绝 | 简单 API 限流，如每秒最多 100 次 |
| 滑动窗口 | 将时间窗口细分为多个小格，滑动统计，避免边界毛刺 | 对精度要求较高的限流场景 |
| 漏桶（Leaky Bucket） | 请求先进入桶中，以固定速率流出；桶满则丢弃 | 平滑流量，适合数据库写入限流 |
| 令牌桶（Token Bucket） | 以固定速率向桶中放入令牌，请求需获取令牌才能通过 | 允许突发流量，Go 标准库 rate 包实现此算法 |
Go 实战提示：Go 标准库
golang.org/x/time/rate 提供了基于令牌桶的高性能限流器，是微服务限流的首选基础组件。配合 sync/atomic 或 channel 可实现分布式限流计数器。
1.2 什么是熔断
熔断（Circuit Breaker）是一种防止故障级联扩散的自我保护机制。当某个下游服务或资源持续出现错误或超时时，熔断器会快速切断对该资源的调用链路，直接返回降级响应，避免调用方线程被长时间阻塞，给下游恢复的时间。
熔断器通常包含三个状态：
- 关闭（Closed）：正常状态，请求直接通过，但会统计失败率。
- 打开（Open）：失败率超过阈值后进入此状态，所有请求直接失败或降级，不发起真实调用。
- 半开（Half-Open）：经过冷却时间后，允许少量探测请求通过，若成功则关闭熔断器，否则继续保持打开。
核心区别：限流是主动预防，在流量到达系统前就进行控制；熔断是被动恢复，在系统已经出现故障后快速隔离，防止雪崩。
1.3 为什么需要限流与熔断
在分布式系统中，单个服务的故障或流量激增很容易引发雪崩效应。以下表格总结了限流与熔断各自解决的核心问题：
| 防护手段 | 解决的问题 | 典型后果（无防护时） |
|---|---|---|
| 限流 | 突发流量、DDoS、爬虫、热点 Key 冲击 | 数据库连接池耗尽、CPU 100%、OOM |
| 熔断 | 下游服务慢响应、连续错误、网络分区 | 调用方线程堆积、资源泄漏、级联崩溃 |
两者结合使用，可以构建多层防御体系：限流在入口处挡住过量请求，熔断在调用链路上隔离故障节点，共同保障系统的整体可用性。
避坑提醒：不要将限流阈值设置得过高或过低。过高则失去保护意义，过低则导致正常用户被误杀。建议结合压测数据与业务容忍度，设置动态调整策略。
1.4 在 Go 微服务中的重要性
Go 语言因其高并发、低延迟的特性，被广泛用于构建微服务网关、API 聚合层、中间件等核心组件。在这些场景中，限流与熔断尤为重要：
- goroutine 轻量但非无限：虽然 goroutine 开销小，但无限制的请求仍会耗尽内存和文件描述符。
- channel 与 select 模式：Go 的并发原语天然适合实现限流器与熔断器的状态机。
- 中间件生态丰富：如
go-kit、go-zero、kratos等框架均内置限流熔断组件，但理解其原理才能正确配置。 - 云原生部署：在 Kubernetes 环境中，限流熔断是服务网格（Service Mesh）和 API 网关的核心能力，Go 编写的 sidecar 代理（如 Envoy 的 Go 扩展）需要高效实现这些逻辑。
下图展示了限流与熔断在 Go 微服务调用链中的典型位置与协作关系：
1.5 限流与熔断的协作关系
限流和熔断并非孤立存在，它们在微服务架构中形成纵深防御：
- 限流在前：在网关层或服务入口处，限流器优先拦截超出系统容量的请求，保护所有下游服务。
- 熔断在后：在服务调用链内部，熔断器针对特定下游节点进行故障隔离，防止局部故障扩散。
- 共同目标：保证核心业务在异常场景下仍能提供有损服务，而非完全不可用。
下图展示了限流与熔断在时间维度的协作流程：