用 gRPC 替代 net/rpc 是降低延迟的第一步，因其基于 Protocol Buffers 和 HTTP/2，具备二进制编码、多路复用、头部压缩等低延迟优势，并需配合连接复用、合理负载均衡、内存复用、GC 优化及拦截器观测等实操措施。
用 gRPC 替代 net/rpc 是降低延迟的第一步
net/rpc 基于文本编码（如 JSON 或 Gob），序列化/反序列化开销大，且默认使用 HTTP/1.1，无法复用连接、不支持流控和头部压缩。而 gRPC 默认基于 Protocol Buffers + HTTP/2，二进制编码紧凑，多路复用、头部压缩、服务端推送等特性天然适合低延迟场景。
实操建议：
- 定义
.proto文件时避免嵌套过深或重复字段，减少序列化体积 - 启用
WithBlock()仅在初始化连接时使用，运行时应配合WithTimeout()和重试逻辑 - 客户端复用同一个
*grpc.ClientConn，不要每次调用都grpc.Dial() - 服务端开启
KeepaliveParams，防止连接被中间设备（如 NAT、LB）静默断开导致首包重连延迟
控制 gRPC 连接粒度与负载均衡策略
单连接 vs 多连接不是简单“越多越好”。连接数过少易成瓶颈，过多则触发文件描述符限制、增加调度开销，尤其在高并发短连接场景下反而抬高 P99 延迟。
关键配置点：
立即学习“go语言免费学习笔记（深入）”；
- 客户端设置
grpc.WithTransportCredentials(insecure.NewCredentials())（开发期）或credentials.NewTLS(...)（生产），避免 TLS 握手阻塞 - 使用
grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy": "round_robin"}`)显式指定策略，避免依赖 DNS-SD 的不确定行为 - 若后端是 Kubernetes Service，优先用
dns:///myservice.default.svc.cluster.local:50051而非硬编码 IP+端口，配合RoundRobin实现客户端负载均衡 - 禁用
grpc.WithWriteBufferSize()和grpc.WithReadBufferSize()的默认值（32KB），根据平均 payload 调整为 64KB 或 128KB，减少缓冲区拷贝次数
避免在 RPC 调用路径中触发 GC 或系统调用
Go 的 GC 停顿（尤其是 STW 阶段）会直接卡住 goroutine，表现为偶发性、不可预测的数十毫秒延迟尖刺。常见诱因包括频繁小对象分配、fmt.Sprintf、strings.ReplaceAll、未复用 bytes.Buffer 等。
实操建议：
- 服务端 handler 中禁止使用
log.Printf，改用结构化日志库（如zap）并预分配logger.With(zap.String("req_id", reqID)) - 对 request/response 结构体启用
proto.Message的Reset()方法复用内存，或使用github.com/gogo/protobuf的unsafe模式（需严格测试） - 禁用
runtime.GC()手动触发；通过GOGC=20环境变量收紧 GC 频率（默认 100），但需监控堆增长趋势 - 用
pprof抓取/debug/pprof/gc和/debug/pprof/heap，确认延迟尖刺是否与 GC 周期吻合
用 grpc-go 的拦截器做细粒度延迟观测与熔断
仅靠 Prometheus 的 grpc_server_handled_latency_seconds 无法定位是网络、序列化、业务逻辑还是下游依赖导致延迟升高。必须在 client/server 端植入轻量级拦截器，打点到纳秒级，并关联 traceID。
func loggingUnaryClientInterceptor() grpc.UnaryClientInterceptor {
return func(ctx context.Context, method string, req, reply interface{}, cc *grpc.ClientConn, invoker grpc.UnaryInvoker, opts ...grpc.CallOption) error {
start := time.Now()
err := invoker(ctx, method, req, reply, cc, opts...)
log.Printf("RPC %s latency=%v err=%v", method, time.Since(start), err)
return err
}
}
更进一步：
- 在拦截器中注入 OpenTelemetry trace，把
ctx透传到下游，形成完整链路 - 对高频低价值接口（如健康检查）启用
grpc.FailFast(false)避免因单次超时直接失败，改用指数退避重试 - 结合
gobreaker在拦截器中实现基于错误率/延迟百分位的熔断，例如连续 5 次 P95 > 200ms 则打开熔断器 - 注意：拦截器本身不能有阻塞 IO 或长耗时计算，否则会放大延迟，所有日志/上报必须异步或带采样（如 1%）
