用 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 延迟。

关键配置点：

• 客户端设置 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%）