1. 限流熔断概述
1.1 限流与熔断的定义
在微服务架构中，限流（Rate Limiting）与熔断（Circuit Breaking）是保障系统稳定性的两大核心手段。两者目标一致——防止局部故障扩散为系统性雪崩，但作用阶段与机制不同。
| 概念 | 定义 | 作用阶段 | 典型触发条件 |
|---|---|---|---|
| 限流 | 控制单位时间内请求的通过量，超出阈值的请求被直接拒绝或排队 | 请求进入服务前 | QPS 超过预设阈值、并发数超过上限 |
| 熔断 | 当下游服务或资源持续故障时，主动切断调用链路，快速失败而非等待超时 | 调用下游服务时 | 错误率/超时率超过阈值、连续失败次数达到窗口上限 |
核心区别：限流是预防性控制，保护自身不被过量请求压垮；熔断是反应性保护，防止对已故障下游的无效等待与资源浪费。
1.2 在微服务中的重要性
微服务架构中，一次用户请求往往跨越 5～15 个服务节点。任意一个节点的延迟或失败，都可能通过同步调用链逐级放大，最终导致整个集群的资源耗尽——这就是经典的雪崩效应。
- 防止资源耗尽：限流确保单个服务不会因突发流量占满 CPU、内存或连接池，为其他服务留出运行空间。
- 隔离故障范围：熔断将故障限制在局部服务内，避免故障沿调用链扩散到上游服务。
- 提升用户体验：快速失败（返回 429/503）比长时间阻塞后超时更友好，客户端可及时降级或重试。
- 保障 SLA：在流量高峰时，限流熔断保证核心链路的吞吐与延迟达标，非核心请求可被降级。
审计关注点：生产环境中，限流熔断配置缺失或阈值设置不合理是导致线上故障的常见根因。基线审计应重点检查每个对外接口是否配置了限流规则，以及每个 RPC 调用是否配置了熔断器。
1.3 Go 语言中的常见实现方式
Go 语言凭借其高并发原生支持（goroutine + channel）和丰富的中间件生态，在限流熔断领域拥有多种成熟实现。以下按实现层次分类：
| 实现方式 | 代表库/方案 | 核心原理 | 适用场景 |
|---|---|---|---|
| 计数器限流 | 标准库 sync/atomic + time.Ticker | 固定时间窗口内累计请求数，超阈值则拒绝 | 简单接口、低精度限流 |
| 令牌桶限流 | golang.org/x/time/rate | 以恒定速率向桶中放入令牌，请求需获取令牌才能通过 | 平滑突发流量、API 网关 |
| 漏桶限流 | uber-go/ratelimit | 请求以固定速率流出，超出桶容量的请求被丢弃 | 严格匀速处理、数据库写入限流 |
| 滑动窗口限流 | 自定义实现 / sentinel-golang | 将时间窗口细分为多个小格，滑动统计粒度更细 | 高精度限流、秒杀场景 |
| 熔断器 | sony/gobreaker / sentinel-golang | 三种状态：关闭 → 打开 → 半开，基于错误率自动切换 | RPC 调用保护、数据库连接保护 |
| 自适应限流 | alibaba/sentinel-golang | 根据系统负载（CPU、RT、并发数）动态调整限流阈值 | 复杂微服务、动态流量环境 |
审计建议：在 Go 项目中，优先使用
golang.org/x/time/rate（官方扩展库）实现令牌桶限流，使用 sony/gobreaker 实现熔断器。这两个库代码简洁、测试覆盖率高、社区活跃，适合作为基线审计的推荐依赖。
1.4 限流熔断的审计基线要点
在 Go 微服务项目中，限流熔断的审计基线应覆盖以下维度：
- 配置完整性：每个对外 HTTP/gRPC 接口是否配置了限流规则？每个 RPC 调用是否配置了熔断器？
- 阈值合理性：限流 QPS 阈值是否基于压测数据设定？熔断的错误率阈值是否与 SLA 对齐？
- 降级策略：被限流或熔断的请求是否有明确的降级响应（如返回默认值、缓存数据）？
- 监控告警：限流触发次数、熔断器状态切换是否有 Prometheus 指标暴露和告警规则？
- 代码侵入性：限流熔断逻辑是否通过中间件/拦截器统一注入，而非散落在业务代码中？
基线检查示例：在审计中，若发现某个核心 RPC 调用未配置熔断器，或限流阈值设置为 0（实际未生效），应标记为高危风险项。