gRPC跨机房调用需配置keepalive保活、显式超时控制、自定义DNS解析及HTTP/2流控调优，否则空闲断连、DNS缓存、流控阻塞等会导致150–300ms延迟毛刺。
gRPC连接复用必须配keepalive，否则跨机房空闲断连很常见
跨机房调用最典型的延迟毛刺，不是发生在业务请求时，而是第一次请求或空闲后下一次请求——因为中间网络设备（如云厂商SLB、NAT网关）默认60秒空闲就静默断开TCP连接。此时gRPC客户端会触发重连：DNS解析 + TCP三次握手 + TLS协商，实测在跨AZ或跨地域场景中可增加150–300ms延迟。
解决方法不是“多试几次”，而是让连接主动保活：
-
grpc.WithKeepaliveParams(keepalive.KeepaliveParams{Time: 30 * time.Second, Timeout: 10 * time.Second})：每30秒发一次keepalive探针，超时10秒即认为连接失效 - 服务端也需配置对应
keepalive.ServerParameters，否则单向保活无效 - 避免把
Time设得太小（如5s），否则可能被防火墙限频或误判为攻击流量 - 连接池复用的前提是
grpc.Dial只调用一次，并全局复用*grpc.ClientConn，不能每次请求都Dial
context.WithTimeout必须设在调用层，不能只靠http.Client.Timeout
很多Go开发者以为给http.Client设了Timeout就万事大吉，但这个字段只控制连接建立和读响应头阶段，不覆盖整个请求生命周期。跨机房场景下，下游服务可能已接收请求但处理缓慢，上游却还在等响应体——此时http.Client.Timeout早已失效，goroutine持续阻塞。
正确做法是每一层调用都显式传入带截止时间的ctx：
- HTTP调用：
req = req.WithContext(ctx)，再传给client.Do(req) - gRPC调用：
client.GetUser(ctx, req)，ctx必须来自context.WithTimeout(parentCtx, 1200*time.Millisecond) - 超时值建议略大于下游P95延迟（比如压测得P95=950ms，设1200ms），太短会导致误超时，太长放大雪崩风险
- 务必
defer cancel()，否则timer泄漏会缓慢耗尽系统资源
DNS解析要绕过系统缓存，改用自定义resolver + TTL控制
跨机房服务发现常依赖域名（如user-service.prod-east.internal），而Go默认使用系统getaddrinfo，其DNS缓存策略不可控：Linux glibc缓存TTL、macOS有独立缓存机制，且无法感知DNS记录变更。一旦DNS返回过期IP，连接就会打到已下线的实例，表现为随机超时或连接拒绝。
生产环境应接管DNS解析逻辑：
- 用
grpc.WithResolvers(customResolver)替换默认resolver - 自定义resolver中调用
net.DefaultResolver.LookupHost并设置Timeout，避免DNS查询本身卡住 - 缓存DNS结果时，严格按记录TTL过期（不是固定时间），并支持后台异步刷新
- 若用etcd/consul做服务发现，建议直接走API拉取endpoint，跳过DNS环节
HTTP/2优先级与流控参数需调优，否则跨机房吞吐上不去
gRPC底层是HTTP/2，但Go标准库的默认流控窗口（64KB）和优先级树策略，在跨机房高延迟链路上容易成为瓶颈：单个大响应会占满流控窗口，阻塞其他并发请求；而默认优先级不区分关键路径与非关键路径，导致埋点日志上报拖慢主流程。
关键参数调整建议：
- 增大初始流控窗口：
grpc.WithInitialWindowSize(256 * 1024)和grpc.WithInitialConnWindowSize(256 * 1024) - 禁用HTTP/2优先级（简化调度）：
grpc.WithDisableHealthCheck()不相关，真正有效的是grpc.WithTransportCredentials配合自定义http2.Transport，其中设AllowHTTP2 = true且MaxConcurrentStreams = 1000 - 对非关键调用（如metric上报），用独立
*grpc.ClientConn隔离，避免影响主调用链路
这些参数不改，光换协议或加机器，跨机房延迟下降有限——延迟毛刺往往藏在协议栈细节里，而不是业务代码中。
