17370845950

Go中RPC并发优化核心是连接复用、批量请求、精细化超时重试及上下文取消，而非盲目增加goroutine；需复用gRPC连接或HTTP Transport，用errgroup限流，并协同服务端流控与压缩。

在 Go 中实现 RPC 并发调用优化，核心不是堆并发数，而是控制好连接复用、请求批处理、超时与重试策略，并合理使用上下文取消机制。盲目增加 goroutine 数量反而容易压垮服务端或耗尽客户端资源。

复用 HTTP/2 或 gRPC 连接

HTTP/1.1 默认每请求建连（除非显式启用 Keep-Alive），而 gRPC 基于 HTTP/2，天然支持多路复用。避免为每次 RPC 新建 client 实例：

• 全局复用一个 *grpc.ClientConn，它本身是线程安全的，可被多个 goroutine 并发调用
• 若用标准 net/rpc + HTTP，确保 Transport 复用：设置 http.DefaultTransport.MaxIdleConns 和 MaxIdleConnsPerHost（建议 ≥ 100）
• 禁用 TLS 会话复用时的证书验证开销（仅测试环境），生产环境务必保留，但可通过 tls.Config.SessionTicketsDisabled = false 启用 ticket 复用

批量请求 + 异步等待（Fan-out）

将多个独立 RPC 请求合并为一次批量调用（如自定义 BatchService），或用 goroutine + channel 并行发起、统一收集结果：

• 用 errgroup.Group 控制并发上限（如 g.SetLimit(16)），避免雪崩
• 每个子请求带上独立 context（带 timeout），防止单个慢请求拖垮整组
• 示例：对 100 个用户 ID 并发查资料，不逐个 go f(id)，而是分 10 组 × 10 并发，每组用 eg.Go 启动

精细化超时与错误分类处理

不同 RPC 调用应有差异化超时策略，且需区分临时性错误（如网络抖动）和永久性错误（如参数校验失败）：

• 用 context.WithTimeout(ctx, 300*time.Millisecond) 替代固定 time.Sleep + select
• 对 codes.Unavailable、codes.DeadlineExceeded 可有限重试（最多 2 次，指数退避）；对 codes.InvalidArgument 直接返回
• 记录 slow RPC（如耗时 > 95 分位阈值）并上报 metric，用于后续容量评估

服务端配合：流控与响应压缩

客户端优化效果受限于服务端能力，需协同设计：

• 服务端启用 gRPC 流控（如 grpc.RPCStatsHandler + 自定义限流中间件）
• 对大响应体开启 gzip 压缩：grpc.WithCompressor(gzip.NewCompressor())
• 避免在服务端做同步 DB 查询后拼装复杂结构体再返回；考虑提前序列化或流式响应（stream.Send()）

不复杂但容易忽略：压测前先确认 DNS 解析是否缓存、是否启用了 TCP Fast Open、服务端文件描述符限制是否足够。吞吐量瓶颈往往不在代码逻辑，而在系统层配置。