gRPC 偶发 503 的隐形根因：HTTP/2 连接复用撞上服务端 GOAWAY 的排查与兜底

结论先行：「偶发、低比例、难复现」的 gRPC 超时 / 503，十有八九不是网络抖动，而是 HTTP/2 连接复用与服务端主动断连（GOAWAY）之间的时间差。客户端复用一条「它以为是活的」长连接发出请求，而服务端刚好在这条连接上发了 GOAWAY——请求撞在半空，表现就是 DEADLINE_EXCEEDED 或 UNAVAILABLE(503)。

一、现象：QPS 2000 的对账服务，每天固定出现 0.03% 的偶发超时

先摆数字。我们一个支付对账服务（客户端 grpc-go v1.62.0，后端 6 个 provider 实例，前面挂 Envoy 1.28 做 L7 代理），QPS 稳定在 2000 左右，P99 一直 45ms。但监控里每天固定出现一小撮 UNAVAILABLE / DEADLINE_EXCEEDED，比例约 0.03%（一天约 50 万请求里 150 个失败）。

关键特征是失败不随机、而是成簇：每次突发都集中在某条连接建立后第 30 分钟左右，且同一时刻多个并发请求一起挂。抓包一看，挂掉的那些请求，TCP 层先收到 GOAWAY，紧接着 RST。

这个特征本身就是线索：30 分钟这个数，正好对得上 Envoy 的 max_connection_age=30m。

二、根因：连接复用的「活连接」假象，与 GOAWAY 的 grace period

HTTP/2 是长连接多路复用，客户端默认会复用一条 TCP 连接发所有请求，只要这条连接没报错，客户端就默认它一直活着。但服务端侧有几种机制会主动关连接：

• Envoy max_connection_age（我们配 30m）：连接活到点就发 GOAWAY 关闭；
• downstream_idle_timeout（默认 1h）：空闲超时；
• 资源紧张时 Envoy 会主动降载。

服务端发 GOAWAY 时不会立即断——它给一个 grace period（max_connection_age_grace），让在途请求跑完。问题就出在这个时间差：

客户端在 GOAWAY 发出的「瞬间之前」，把一条新请求复用到了这条连接上。服务端认为这条连接「不再接新流」，于是对新请求返回 RST_STREAM，或整条 GOAWAY 后 RST。客户端看到的就是连接级错误。

换句话说：连接在「TCP 还通」和「HTTP/2 层已不接新流」之间有一个窗口，而客户端的复用逻辑对这个窗口完全无感知。这就是它偶发、成簇、难复现的原因——它取决于「客户端发包时刻」与「服务端发 GOAWAY 时刻」的相对位置，是纯粹的竞态。

三、具体做法：把「连接生命周期」从服务端手里，也拿到客户端手里

核心思路：客户端要主动参与连接生命周期管理，而不是被动等服务端踢。我们做了三件事：

1. 给客户端配 keepalive（grpc-go）：

keepalive.ClientParameters{
    Time:                30 * time.Second, // 空闲 30s 探测
    Timeout:             10 * time.Second,
    PermitWithoutStream: true,             // 没有活跃流也允许 ping
}
conn, _ := grpc.Dial(target,
    grpc.WithKeepaliveParams(cfg),
    grpc.WithTransportCredentials(insecure.NewCredentials()))

2. 让客户端比服务端更早主动换连接，避免撞在服务端 GOAWAY 上。服务端 max_connection_age=30m，客户端侧 provider 设短一档留安全裕度：

grpc.MaxConnectionAge(25 * time.Minute)
grpc.MaxConnectionAgeGrace(1 * time.Minute)

3. 重试策略只给幂等 RPC 开，指数退避 + 抖动：

# gRPC service config
retryPolicy:
  maxAttempts: 3
  initialBackoff: "0.5s"
  maxBackoff: "2s"
  backoffMultiplier: 2.0
  retryableStatusCodes: [UNAVAILABLE]

四、踩过的坑：两个反直觉的地方

坑 1：keepalive 配太激进，反而被服务端「禁 ping」踢掉。 我们把 Time 调到 10s、PermitWithoutStream=true，结果 Envoy 频繁回 GOAWAY(ENHANCE_YOUR_CALM)，抓包看到 error 是 too_many_pings——Envoy 默认要求「两次 ping 之间至少 5 分钟有数据流」，无数据 ping 太密就判你 ping flood。所以 keepalive 不是越密越好，Time 至少要 ≥ 服务端的 min 限制，我们最终稳定在 30s。

坑 2：把「非幂等」的扣款接口也加了 UNAVAILABLE 重试，造成重复扣款。 UNAVAILABLE 既覆盖「连接被 GOAWAY 掐断」（可安全重试），也覆盖「服务端处理中但中途挂了」（可能已经写库）。我们对一个非幂等的记账 RPC 开了重试，结果某次 provider GC 停顿触发 UNAVAILABLE，重试把同一笔账记了两遍。教训：重试安全性取决于 RPC 本身的幂等性，而不是错误码。非幂等接口必须配合业务幂等键 + 服务端去重（唯一索引），否则宁可失败也不要盲目重试。

五、结论与可复用清单

• 「偶发、成簇、低比例」的 gRPC 超时，第一怀疑对象是连接复用 × 服务端 GOAWAY 的竞态，不是网络。
• 抓包看是不是 GOAWAY + RST，失败时刻是否对齐服务端的 max_connection_age / idle_timeout。
• 客户端三件套：keepalive（Time ≥ 服务端 min，别太密）+ MaxConnectionAge/Grace 主动老化 + 只对幂等 RPC 开 UNAVAILABLE 重试。
• 重试安全性看 RPC 幂等性，不看错误码；非幂等必须配幂等键。
• 相关思路可参考站内程清和那篇「NTP 回拨 12 秒打穿 etcd 租约选主」——本质都是分布式系统里「时钟 / 生命周期的权威方」不在你以为的那一侧。