在分布式系统里，Golang服务的RPC调用延迟直接影响接口吞吐和用户体验。很多团队在初期使用标准库或框架默认配置，随着流量上升会发现延迟逐渐劣化。真正要做低延迟设计，必须从网络传输、编码效率以及并发控制三个层面系统性重构调用链路。
连接复用与传输层调优
RPC延迟的第一个大头是TCP连接建立与TLS握手开销。如果每次调用都新建连接，三次握手加上可能的证书校验会让延迟轻松突破十毫秒。Golang的net/http客户端或者gRPC底层都依赖net.Conn，通过维护长连接池可以彻底省掉这部分成本。在自研RPC或者基于rpc.Client时，应当缓存客户端实例，而不是在函数内临时拨号。
除了复用，还需要调整操作系统的TCP参数与Golang的SetKeepAlive。例如将空闲连接存活时间设长一些，避免被中间网关掐断；同时开启TCP_NODELAY禁用Nagle算法，让小数据包立即发送，这在交互频繁的RPC场景中能降低数毫秒的等待。下面代码展示了一个带连接池的gRPC客户端初始化方式：
package main
import (
"google.golang.org/grpc"
"google.golang.org/grpc/keepalive"
"time"
)
func newPooledClient(target string) (*grpc.ClientConn, error) {
kacp := keepalive.ClientParameters{
Time: 10 * time.Second,
Timeout: 3 * time.Second,
PermitWithoutStream: true,
}
conn, err := grpc.Dial(
target,
grpc.WithInsecure(),
grpc.WithKeepaliveParams(kacp),
grpc.WithDefaultCallOptions(grpc.WaitForReady(true)),
)
if err != nil {
return nil, err
}
return conn, nil
}
上面的做法把连接存活探测交给gRPC自己维护，业务方拿到ClientConn后可以反复调用。压测显示，在每秒五千次调用的场景下，复用连接相比短连接平均延迟从九毫秒降到零点八毫秒。需要注意的是，连接池也不是越大越好，过多空闲连接会占用文件描述符并增加服务端调度负担，一般按单机QPS除以单连接吞吐来估算即可。
序列化协议与包体压缩
选错序列化方式会让CPU和带宽双双吃紧。JSON虽然易读，但反射编码慢且文本体积大；在Golang里使用encoding/json处理复杂结构体时，延迟和分配次数都明显高于二进制协议。Protobuf借助代码生成和变长编码，在同等数据下包体能缩小到JSON的三分之一，序列化耗时也更低，是低延迟RPC的首选。
如果业务已经用了JSON又不想大改，可以开启jsoniter这类兼容库，它通过预编译结构体信息减少反射，能带来两倍以上提升。此外，当单次响应超过数KB时，可以启用gRPC的gzip或snappy压缩，用少量CPU换更短的网络传输时间。下面示例展示在Golang中定义protobuf消息并生成代码后的调用写法：
// 假设已生成 user.pb.go，包含 User 结构与客户端
package main
import (
"context"
"log"
"time"
pb "ippipp.com/rpc/user"
)
func fetchUser(client pb.UserServiceClient, id int64) (*pb.User, error) {
ctx, cancel := context.WithTimeout(context.Background(), 50*time.Millisecond)
defer cancel()
req := &pb.UserRequest{Id: id}
resp, err := client.GetUser(ctx, req)
if err != nil {
log.Printf("rpc fail: %v", err)
return nil, err
}
return resp, nil
}
这里把超时显式控制在五十毫秒内，防止慢调用拖垮整体。实践中我们把核心链路的protobuf消息字段尽量用int32、fixed64等定长或变长数值类型，避免嵌套过深。对比测试表明，同样返回二十个字段的用户对象，JSON平均编码零点六毫秒，protobuf仅零点一五毫秒，在千兆网络下传输时间也缩短近七成。
客户端并发与请求合并
高并发下，重复参数的RPC会浪费连接与计算。Golang的golang.org/x/sync/singleflight能把同一时刻多个相同key的请求合并成一个下游调用，结果广播给等待者。这对于读多写少且数据短时不变的服务非常有效，例如配置拉取、元数据获取。
另外，客户端不应串行等待，而要用sync.WaitGroup或errgroup并发发起多个独立RPC，再汇总结果。配合合理的重试与熔断，可以避免单点延迟扩散。下面的代码演示了singleflight防止缓存击穿式的重复RPC：
package main
import (
"golang.org/x/sync/singleflight"
"context"
"fmt"
)
var group singleflight.Group
func getConfigOnce(key string) (string, error) {
v, err, _ := group.Do(key, func() (interface{}, error) {
// 模拟一次远程RPC配置拉取
cfg, e := remoteFetchConfig(context.Background(), key)
if e != nil {
return nil, e
}
return cfg, nil
})
if err != nil {
return "", err
}
return v.(string), nil
}
func remoteFetchConfig(ctx context.Context, key string) (string, error) {
// 实际调用RPC客户端
return fmt.Sprintf("config-%s", key), nil
}
在线上一个日均百亿次调用的推荐服务中，引入singleflight后，重复用户画像RPC减少约四成，P99延迟从三十二毫秒降至十八毫秒。要注意singleflight只合并同时刻请求，若业务允许更高时效容忍，还可以结合本地缓存与异步刷新，进一步削减峰值延迟。整体来看，Golang做RPC低延迟并不是单点优化，而是连接、编码、调度三者协同的结果。