17370845950

gRPC性能优化需从连接复用、超时控制、序列化精简、服务端资源隔离四层面入手：全局复用ClientConn、显式设Context超时、避免大结构体传输、阻塞操作须响应ctx.Done()。

复用连接，避免频繁建连开销

HTTP/2 或 gRPC 默认支持长连接复用，但若每次调用都新建 client（比如在 handler 内 new grpc.Dial），会反复经历 DNS 解析、TCP 握手、TLS 协商，延迟飙升。正确做法是全局复用一个 *grpc.ClientConn，启动时建立，整个服务生命周期内共享。

示例：

• 在 main 初始化时 dial 并保存到全局变量或依赖容器中
• 确保调用方不调用 conn.Close()，除非服务退出
• 配合 WithBlock() 和 WithTimeout() 控制建连等待，避免阻塞启动

启用流控与合理设置超时

默认 gRPC 客户端无超时，可能因后端卡顿导致调用堆积、goroutine 泄漏。每个 RPC 调用必须显式设 Context.WithTimeout，且服务端也应尊重该 deadline 做快速失败。

建议值参考：

• 内部强依赖服务：300–500ms
• 弱依赖或降级场景：100ms 内，超时直接返回默认值
• 避免所有接口统一用 5s —— 掩盖真实瓶颈，拖慢整体 P99

减少序列化/反序列化负担

Protobuf 本身高效，但字段设计不当仍会拖慢。避免在高频 RPC 中传递大结构体（如含 []byte、嵌套深的 map、未压缩的 base64 图片）。

• 用 optional 和 oneof 减少冗余字段传输
• 对体积敏感字段（如日志上下文、调试信息）单独走 header 或 metadata，不进 message body
• 必要时启用 gRPC 的 compressor（如 gzip），但需权衡 CPU 与带宽

服务端并发与资源隔离

gRPC Server 默认使用 Go 默认调度器，若单个 handler 耗 CPU 或阻塞 IO（如同步 DB 查询、未加 context 的 http.Get），会拖慢其他请求。应做到：

• 所有阻塞操作必须传入 ctx，并在 ctx.Done() 时及时退出
• 对慢依赖（如外部 HTTP、Redis）做熔断或异步 fallback，不串行等待
• 用 runtime.GOMAXPROCS 和 server options（如 MaxConcurrentStreams）防止单实例过载

基本上就这些。延迟优化不是堆参数，而是从连接、超时、数据、执行四个层面逐层收紧。不复杂但容易忽略。