Go 的 net/rpc 不支持负载均衡，需手动封装轮询+健康检查调度器或改用 gRPC；gRPC 原生支持 round_robin 策略及服务发现，且具备 context 传播、Protobuf 编码等优势。
Go 的 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)继续找下一个 - 后台 goroutine 定期对每个节点发起轻量
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)
}
gRPC 是更现实的选择：天然支持 round_robin 和 pick_first 策略
如果可以升级协议，直接用 gRPC 替代 net/rpc 是更省心的方案。它原生通过 grpc.WithBalancerName("round_robin") 启用客户端负载均衡，配合 resolver.Builder 接入服务发现。
立即学习“go语言免费学习笔记（深入）”；
注意几个实际易错点：
-
grpc.Dial的target必须是dns:///example.com或自定义 scheme（如etcd://...），不能是具体 IP 地址，否则 balancer 不生效 - 默认 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 也能拿到连接元信息。
这些细节不会报错，但会在高并发下暴露为延迟毛刺、日志无法串联、权限校验丢失等问题。
