go-zero 服务治理实战：熔断、限流、降级 3 道闸门 10 分钟配好

go-zero 服务治理实战：熔断、限流、降级 3 道闸门 10 分钟配好

【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero

上周有个依赖接口开始偶发超时。单个超时不可怕，可怕的是超时把连接占住不放，主服务 RT 跟着爬，后面整条链路一起拖死。复盘下来一句话：我们把所有故障流量都原封不动地丢给了下游。go-zero 服务治理要解决的就是这件事——在请求路径上装三道闸门，让故障只坏在它该坏的地方。下面按一个请求的真实路径走一遍，每道闸门怎么配、参数怎么定，看完就能动手。

go-zero 服务治理三道闸门流程图

第一道闸门 · 限流：请求进门之前 🔒

限流解决的是"我处理得过来才让你进"。go-zero 在 core/limit/ 实现了令牌桶，还带一个按小时/天计数的PeriodLimiter，做"每天限 N 次"这类场景够用。

先想清楚一个取舍：令牌桶允许突发——桶里攒的令牌可以一口气花掉；漏桶则是匀速流出，再猛的洪峰也要排队。选哪个取决于下游：下游是数据库这种怕毛刺的，想要漏桶式平滑；下游能扛短时突发，就用令牌桶。go-zero 内置的是令牌桶，因为大多数 gRPC 服务需要这点弹性。

然后是单机还是分布式。TokenLimiter走 Redis，用一段 Lua 脚本保证扣令牌是原子的，多个实例共享一个桶；如果 Redis 挂了，它会自动切到本地xrate限流器兜底，限流功能本身不会因为 Redis 故障而失效。单个实例、流量不大的场景，直接用本地限流器就行，别为了"分布式"多引入一个依赖。

限流参数 rate/burst 怎么定

# rate: 每秒稳定放行的请求数，burst: 桶的容量（允许的突发量） limiter: limit.NewTokenLimiter(200, 400, rdb, "order-api")

• rate定在压测出的单机吞吐的 80% 左右，留点余量给重试和毛刺；
• burst一般取 rate 的 1.5~2 倍，流量波动大的接口可以放大，但别大到让限流形同虚设。

避坑：多实例共享一个桶 key 时，rate 要按集群总容量算，写成单机容量等于把自己限死了。

第二道闸门 · 熔断：依赖开始出问题时 ⚡

限流防的是"太多人"，熔断防的是"那个人病了"。依赖开始超时、报错，你再往它身上打流量就是在陪葬。

三态熔断 30 秒看懂

三句话说透：Closed状态正常放行，但持续统计失败；失败一多，Open状态开始按比例丢弃请求，相当于主动跳过这个依赖；每隔 1 秒放一个请求去探测，探通了就恢复，探不通就继续断。

go-zero 的实现在 core/breaker/googlebreaker.go：一个 10 秒的滚动窗口切成 40 个桶，每 250 毫秒一桶。失败桶越多，丢弃概率自适应地升高，不是一刀切，也不会永远断死。

接入成本几乎为零。zrpc 的客户端和服务端都内置了 breaker 拦截器（zrpc/internal/clientinterceptors/、zrpc/internal/serverinterceptors/），每个"目标地址 + 方法"一个独立熔断器，配置里默认就是开着的：

Middleware: Breaker: true # 默认即 true，显式写上是为了关的时候不手抖 Timeout: true

哪些错误算"依赖失败"

这是个容易配错的地方。go-zero 用 zrpc/internal/codes/ 里的Acceptable来区分：Unavailable、DeadlineExceeded、Internal、ResourceExhausted这类基础设施错误，说明依赖本身不健康，计入失败、驱动熔断；而NotFound这类业务错误只是"没查到数据"，服务是健康的，不算它头上。如果你的下游把业务失败也返回Internal，熔断器会被业务错误误伤——先把下游的错误码规范理干净。

避坑：别手搓一个全局 breakerName 包住所有方法，一个慢接口会把好接口一起熔掉；框架默认按方法隔离，就让它隔离着。

第三道闸门 · 降级：兜不住的时候 🛟

熔断决定"不放行"，降级决定"不放行的时候给用户看什么"。原则就一条：先保住收银台，把非核心的先摘掉。

熔断丢弃请求时，DoWithFallback会立刻调你的兜底函数，不等、不阻塞：

err := breaker.DoWithFallbackCtx(ctx, func() error { resp, err = userClient.GetUser(ctx, req) return err }, func(error) error { resp = getCachedUser(req.Id) // 回退到缓存或默认值 return nil })

三件事配齐才算完整的降级：

1. 熔断打开后返回什么——缓存、默认值、静态文案，按接口重要程度选；
2. 超时怎么兜底——客户端中间件里开Timeout，还能按方法配MethodTimeout，别等熔断反应过来，连接先挂掉；
3. 回退数据怎么标——给响应打个"降级数据"的标记，前端能区分真假，别让降级数据被当成实时数据缓存下来。

避坑：默认值别做成"看起来正常"的假数据，用户拿着假地址下单，比页面报错严重十倍。

参数速查：一张表查完

所属闸门	参数	内置默认 / 建议值	调参方向
限流	rate（稳定 QPS）	无内置值，取压测吞吐 80%	429 偏多每次上调 20%，RT 冲高则下调
限流	burst（突发容量）	建议 1.5~2 倍 rate	流量波动大调大，别大到限流失效
限流	存储模式	Redis 分布式，故障自动切本地	单实例直接本地限流，不引 Redis
熔断	滚动窗口	10 秒 / 40 桶（250ms 每桶）	窗口越短反应越快，但样本越少越噪
熔断	强制探测间隔	1 秒放一个探测请求	依赖恢复慢就调大，减少无效探测
降级	方法级超时	无默认，建议 1~3 秒	对齐依赖的 P99 延迟
降级	可接受错误	见codes.Acceptable列表	业务错误不背依赖的锅

可观测性：接入 Prometheus 看什么

zrpc 的 Prometheus 拦截器默认开启（Middleware.Prometheus: true），重点盯两组指标：按 gRPC 状态码统计的请求量，和调用耗时分布。前者里Unavailable、DeadlineExceeded占比爬升，往往先于熔断发生，是你介入的黄金窗口；后者用来校准超时和 rate 参数。熔断丢弃请求时还会通过stat.Report打出带近期错误原因的日志，按 "breaker is open" 关键字就能检索到现场。

指标名清单：

• zrpc_client_requests_code_total/zrpc_server_requests_code_total：按状态码的请求计数
• zrpc_client_request_duration_ms/zrpc_server_request_duration_ms：调用耗时直方图

写在最后

线上出问题的时候，你最希望系统"坏得其所"：一个依赖挂掉，只影响依赖它的那几个接口，剩下的照常跑。三道闸门配完，别马上收工——盯上code_total和duration_ms的曲线，等熔断在真实流量里跳过一次闸，你再回头微调参数，心里才有底。更多细节可以直接翻仓库里 core/breaker/、core/limit/ 和 zrpc 拦截器目录，源码量不大。

【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero