RPC 核心概念 05超时、重试、熔断与限流如果说服务发现是 RPC 的基础设施那么超时、重试、熔断、限流就是 RPC 的安全气囊——决定了系统在故障来临时还能否站立。本篇讲清楚这四件套的边界、配合与陷阱。一、为什么需要这些分布式调用链中任何一环都可能突然变慢偶发抖动整体不可用流量洪峰冲击。如果不加防护慢调用会耗尽线程/goroutine偶发错误会蔓延至上游故障会雪崩式放大。所以每一次跨网络调用都必须有超时、重试、熔断、限流策略这是工业 RPC 的铁律。二、超时Timeout2.1 为什么超时是第一道防线“网络请求没有超时 自杀。”没有超时 调用方线程/goroutine 永远悬挂 资源耗尽 整体宕机。2.2 超时层级[用户请求] │ 整体超时 5s ▼ [网关] │ 调下游 A 超时 3s ▼ [服务A] │ 调下游 B 超时 1s ▼ [服务B]经验法则上游超时 ≥ 下游所有调用之和同一接口对不同调用方可有不同超时写操作超时要慎重重试可能造成幂等问题。2.3 上下文传递context.ContextGo 的context是天然的超时载体ctx,cancel:context.WithTimeout(ctx,1*time.Second)defercancel()resp,err:client.Call(ctx,req)关键设计所有 RPC 框架都会把ctx透传给下游使整条调用链共享 deadline。tRPC、gRPC 都遵循这一规则。2.4 超时常见错误错误后果整体业务超时大于 SDK 超时实际超时由 SDK 决定不带 cancel资源泄漏超时太长流量打爆下游超时太短误判正常请求三、重试Retry3.1 重试的基本原则✅ 应该重试网络超时503 / 5xx连接失败。❌ 不应该重试业务错误参数错、权限错4xx已扣款的支付。3.2 幂等性重试的前提是接口幂等——同样的请求重复调用结果一致。幂等性实现天然幂等GET、删除、ID 唯一约束请求 ID 去重每次请求带request_id服务端缓存已处理乐观锁UPDATE ... WHERE version X。3.3 退避策略不能立即重试否则会暴击故障下游固定退避500ms → 500ms → 500ms指数退避100ms → 200ms → 400ms → 800ms指数退避 抖动推荐delay min(cap, base * 2^n) ± random抖动能避免大量调用方同步暴击。AWS 推荐做法sleep:rand.Float64()*math.Min(cap,base*math.Pow(2,n))3.4 重试预算Retry Budget无脑重试会放大下游压力。Google 提出重试预算重试比例 ≤ 10% 总流量超过则禁用重试一段时间保护下游。3.5 tRPC 配置示例client:service:-name:trpc.app.usertimeout:1000# msretry:2四、熔断Circuit Breaker4.1 熔断的本质下游已经挂了/极慢继续打无意义且伤害自己。熔断器在错误率达到阈值时主动拒绝请求给下游恢复时间。4.2 三态状态机┌────────────┐ │ Closed │ ← 正常全量放行 └─────┬──────┘ │ 错误率 阈值 ▼ ┌────────────┐ │ Open │ → 快速失败全部拒绝 └─────┬──────┘ │ 冷却时间到 ▼ ┌────────────┐ │ Half-Open │ → 放少量探测请求 └─────┬──────┘ 成功 │ 失败 ↓ ↓ Closed Open4.3 关键参数错误率阈值通常 50%统计窗口滚动窗口如最近 10s最小调用数避免低流量误判冷却时间通常 5~30s探测请求数half-open 状态放行的请求数。4.4 算法Sliding Window[ 1s | 1s | 1s | ... | 1s ] ← 10 个桶 合计错误率 → 决策Google SRE《SRE 工作手册》算法拒绝概率 max(0, (requests - K * accepts) / (requests 1))K 通常取 2自适应、无明显状态切换、被广泛采用如 Kratos。4.5 与限流的边界维度熔断限流触发原因错误率高流量太大保护对象自己避免被慢调用拖垮下游避免被打爆/ 自己五、限流Rate Limiting5.1 为什么需要限流保护下游不被打爆防御异常流量爬虫、攻击公平分配资源给多租户。5.2 限流维度全局 → 接口 → 调用方 → 用户 → IP通常组合使用比如每个 IP 每秒最多 10 次 整体 QPS 不超过 1 万。5.3 主流算法计数器最简单每秒 N 次。缺点边界突刺59.999s 来 N 次 60.001s 又来 N 次 1 秒内 2N 次。滑动窗口把 1 秒分成多个小桶更精细。漏桶Leaky Bucket[流量] → ████ → [桶] → 匀速流出 → [服务]平滑流量但不能应对短时突发。令牌桶Token Bucket[匀速生成 token] → [桶] ← [请求需要拿到 token]允许突发桶里攒了 N 个 token 可一次消费完是最常用算法。Go 标准库golang.org/x/time/rate就是令牌桶实现limiter:rate.NewLimiter(100,200)// 100 QPS桶容量 200if!limiter.Allow(){returnerrors.New(rate limited)}5.4 分布式限流单机限流在多实例场景失效。常见方案Redis Lua分布式计数Sentinel / Polaris内置分布式限流网关层限流在入口统一控流。六、降级Fallback当下游不可用返回兜底数据推荐服务挂了 → 返回热门兜底个性化页面挂了 → 返回静态页关键服务挂了 → 直接报错不能瞎降级。resp,err:client.Recommend(ctx,req)iferr!nil{returndefaultHotItems,nil// 降级}returnresp,nil七、四件套协同[客户端] │ ▼ [限流]流量太大直接拒绝 │ ▼ [熔断]下游挂了直接拒绝 │ ▼ [超时]调用必须有 deadline │ ▼ [重试]偶发错误幂等重试 │ ▼ [降级]兜底数据八、tRPC-Go 配置实战client:service:-name:trpc.app.usertarget:polaris://trpc.app.usertimeout:500# msretry:2plugins:circuitbreaker:polaris:{}# 走 Polaris 熔断ratelimiter:polaris:{}# 走 Polaris 限流代码层显式控制ctx,cancel:context.WithTimeout(ctx,500*time.Millisecond)defercancel()resp,err:client.GetUser(ctx,req,client.WithTimeout(500*time.Millisecond),)九、可观测性配套四件套必须配备指标超时率重试次数 / 重试成功率熔断次数 / 熔断恢复时间限流拒绝数通过 Prometheus Grafana 大盘可视化结合告警闭环错误率突增 → 告警 → 自动扩容 / 切流十、踩坑清单❌ 重试非幂等接口 → 资金事故❌ 上游超时 下游超时之和 → 重试无用功❌ 不带退避的重试 → 故障放大❌ 关键服务无脑降级 → 数据错误流到用户❌ 单机限流认为是全局 → 限流策略失效❌ 熔断阈值过严 → 抖动即误熔❌ 网关侧已限流但内部不再限流 → 内部某节点被打爆。十一、小结超时Deadline 必须随调用链层层下传重试幂等 退避 预算熔断三态机错误率阈值保护自己限流令牌桶最常用分布式靠 Redis/Sentinel降级兜底数据不能盲目用。至此RPC 核心概念 5 篇完结。下一阶段我们正式进入tRPC-Go 框架的世界看它如何把这些理念落地为开箱即用的工程能力。