用gRPC替代HTTP/1.1 JSON API是最直接的降延迟手段，因其基于HTTP/2和Protocol Buffers，具备二进制序列化快、多路复用、头部压缩等优势，实测可降低RTT 2–5ms。

用 gRPC 替代 HTTP/1.1 JSON API 是最直接的降延迟手段

HTTP/1.1 的文本解析、连接复用限制和头部冗余，会让微服务间 RTT 稳定高出 2–5ms（实测中等负载下）。gRPC 默认基于 HTTP/2 + Protocol Buffers，二进制序列化快、支持流式、头部压缩、多路复用——同一连接可并发处理数十个请求，避免了 TCP 建连和 TLS 握手开销。

实操建议：

• 定义 .proto 文件时，避免嵌套过深或使用 any 类型，否则反序列化耗时会上升；
• 服务端必须启用 KeepaliveParams，否则空闲连接会被中间代理（如 Nginx、Envoy）主动断开，导致后续请求触发重连；
• 客户端初始化 grpc.Dial 时，显式设置 WithBlock() 和超时，避免阻塞启动，例如：

  conn, err := grpc.Dial("service:8080",
      grpc.WithTransportCredentials(insecure.NewCredentials()),
      grpc.WithBlock(),
      grpc.WithTimeout(3*time.Second))

context.WithTimeout 必须贯穿所有 RPC 调用链

没有上下文超时的 gRPC 调用，一旦下游卡住，会拖垮整个调用链，引发级联延迟。Golang 的 context 不是装饰品，它是控制传播、取消和截止时间的唯一可靠机制。

常见错误现象：

• 用 context.Background() 直接发起 client.Call(ctx, req)，上游已超时但下游仍在跑；
• 在 HTTP handler 中用了 r.Context()，但没把该 context 传给 gRPC client 调用；
• 跨 goroutine 传递 context 时漏掉，比如在 go func() { ... }() 里直接用全局 context。

正确做法：从入口开始逐层透传，并根据 SLA 设置合理 deadline。例如，一个对外 200ms 的接口，内部 RPC 应设为 context.WithTimeout(ctx, 150*time.Millisecond)，留出序列化与网络缓冲余量。

避免在热路径上做 JSON 编解码或日志全量打印

微服务高频通信场景下，json.Marshal/json.Unmarshal 比 proto.Marshal 慢 3–8 倍（尤其含嵌套 map/slice），且 GC 压力显著上升。同理，log.Printf("%+v", hugeStruct) 会触发反射遍历+字符串拼接，在 QPS 过万时可能吃掉 10%+ CPU。

使用场景判断：

• 仅调试阶段需要结构体内容？改用 fmt.Sprintf("%#v", x) + 日志采样（如 if rand.Intn(100) == 0）；
• 必须记录请求体？先判断是否启用了 debug 模式，再选择性 encode；
• 日志字段尽量用 key-value 形式：log.Info("rpc_call", "method", "GetUser", "uid", uid, "took_ms", d.Milliseconds())，避免格式化开销。

http.Transport

和 grpc.DefaultClientConnBuilder 的默认值不适用于高并发微服务

Golang 标准库的 HTTP 客户端和 gRPC 默认连接池都偏保守：HTTP 默认 MaxIdleConnsPerHost = 2，gRPC 默认不复用连接（除非显式配置 WithTransportCredentials 并启用 keepalive）。这会导致连接频繁新建/销毁，TLS 握手成为瓶颈。

性能关键配置项：

• HTTP client：设置 MaxIdleConns 和 MaxIdleConnsPerHost ≥ 100，IdleConnTimeout ≥ 90s；
• gRPC client：务必配 grpc.WithKeepaliveParams(keepalive.KeepaliveParams{Time: 30 * time.Second})；
• 若用 http.Client 调其他服务（如第三方 webhook），禁用 CheckRedirect，并设 Timeout 防止 hang 住。

这些参数不写进代码而是通过配置中心注入，上线后可动态调优。

延迟优化不是堆参数，而是识别哪一跳真正耗时——用 pprof 抓 net/http/pprof 的 goroutine 和 trace，比盲调 MaxConns 有用十倍。另外，跨机房调用再怎么优化协议，也难敌物理距离，geo-routing 和本地缓存才是更高阶解法。