Go 的 net/rpc 不支持负载均衡,需手动封装轮询+健康检查调度器或改用 gRPC;gRPC 原生支持 round_robin 策略及服务发现,且具备 context 传播、Protobuf 编码等优势。
net/rpc 本身不支持负载均衡,必须自己封装或换库标准库 net/rpc 只提供点对点通信能力,rpc.Client 固定连接单个服务端地址,没有内置的客户端重试、健康检查或请求分发逻辑。想实现负载均衡,只能在调用层做抽象——要么手写调度器,要么改用支持服务发现的 RPC 框架(如 gRPC + etcd / consul)。
如果你受限于必须用 net/rpc(例如遗留系统、轻量内部服务),核心思路是:把 *rpc.Client 的创建和调用过程收口,由一个 LoadBalancer 类型统一管理后端节点列表、选择策略与故障熔断。
最常用且可控的方式是基于 sync/atomic 和 time.AfterFunc 实现带心跳探测的轮询(Round Robin)。关键点不是“选哪个”,而是“选完之后连不上怎么办”。
个后端节点维护一个 healthy 原子布尔值,初始为 true
!healthy 则跳过,用 atomic.AddUint64(&idx, 1) 继续找下一个rpc.Call(比如调用 "" 方法或预设的 Ping 方法),失败则置 healthy = false,成功则恢复500ms,且用独立 context 控制type Node struct {
addr string
client *rpc.Client
healthy uint32 // 0=false, 1=true
mu sync.RWMutex
}
func (n *Node) Call(serviceMethod string, args interface{}, reply interface{}) error {
n.mu.RLock()
if atomic.LoadUint32(&n.healthy) == 0 {
n.mu.RUnlock()
return errors.New("node unhealthy")
}
client := n.client
n.mu.RUnlock()
return client.Call(serviceMethod, args, reply)
}
round_robin 和 pick_first 策略如果可以升级协议,直接用 gRPC 替代 net/rpc 是更省心的方案。它原生通过 grpc.WithBalancerName("round_robin") 启用客户端负载均衡,配合 resolver.Builder 接入服务发现。
注意几个实际易错点:
grpc.Dial 的 target 必须是 dns:///example.com 或自定义 scheme(如 etcd://...),不能是具体 IP 地址,否则 balancer 不生效pick_first,要显式指定 round_robin
grpc.KeepaliveParams,否则连接空闲后可能被中间设备断开conn, err := grpc.Dial(
"etcd:///my-service",
grpc.WithTransportCredentials(insecure.NewCredentials()),
grpc.WithBalancerName("round_robin"),
grpc.WithResolvers(etcdBuilder),
)
if err != nil {
log.Fatal(err)
}
负载均衡只是第一层,真正影响吞吐的是编解码和跨节点 trace 透传。用 net/rpc 默认的 gob 编码,结构体字段名变化就会导致兼容性断裂;而 gRPC 强制使用 Protocol Buffers,天然支持向后兼容。
另外,如果你需要透传请求 ID、认证 token 或超时控制,net/rpc 没有 context 支持,只能靠在 args 里硬塞字段;gRPC 的 context.Context 可直接携带 metadata,服务端用 grpc.Peer 和 grpc.RequestInfo 也能拿到连接元信息。
这些细节不会报错,但会在高并发下暴露为延迟毛刺、日志无法串联、权限校验丢失等问题。