Go 的 net/rpc 不支持负载均衡，需在客户端封装轮询代理并复用 *rpc.Client 连接，配合连接健康检查；生产环境推荐改用 grpc-go，其原生支持服务发现与多种 LB 策略。
Go 的 net/rpc 本身不支持负载均衡
直接用标准库 net/rpc 拨号到单个地址（如 rpc.Dial("tcp", "10.0.1.10:8080")）时，所有请求都发往同一节点。它没有内置服务发现、健康检查或轮询逻辑——你得自己补上这一层。
常见做法是把 RPC 客户端封装成一个带策略的代理，由它决定每次调用该连哪个后端。关键不是改服务端，而是改造客户端初始化和调用路径。
用 rpc.Client + 自定义连接池实现轮询
最轻量的方案是维护一组 *rpc.Client 实例，配合一个简单的轮询索引。注意：每个 *rpc.Client 底层对应一个长连接，别在每次请求时新建，否则开销大且易触发连接数限制。
- 预先建立并复用
*rpc.Client，用sync.Pool或切片缓存 - 轮询需线程安全，用
atomic.AddUint64(&idx, 1) % uint64(len(clients)) - 必须处理连接失效：调用前检查
client.Go是否返回非 nil error；失败后应标记该 client 不可用，并跳过（可配合简单重试）
type RoundRobinClient struct {
clients []*rpc.Client
idx uint64
}
func (r *RoundRobinClient) Call(serviceMethod string, args interface{}, reply interface{}) error {
n := uint64(len(r.clients))
i := atomic.AddUint64(&r.idx, 1) % n
client := r.clients[i]
return client.Call(serviceMethod, args, reply)
}
结合 grpc-go 更适合生产级负载均衡
如果你能接受替换协议，grpc-go 是更现实的选择：它原生支持 DNS、DNS-SD、etcd 等服务发现机制，并内置 round_robin、pick_first 等负载均衡策略，还能自动重连与健康探测。
立即学习“go语言免费学习笔记（深入）”；
标准 net/rpc 的 HTTP 传输层太简陋，无法承载 LB 所需的元数据透传（如超时、标签路由），而 gRPC 的 ClientConn 可通过 WithBalancerName("round_robin") 直接启用：
conn, err := grpc.Dial(
"dns:///my-service.example.com",
grpc.WithTransportCredentials(insecure.NewCredentials()),
grpc.WithDefaultServiceConfig(`{"loadBalancingConfig": [{"round_robin": {}}]}`),
)
这比手撸连接池稳定得多，尤其当后端节点动态扩缩时。
别忽略错误传播与超时控制
无论用哪种方式，RPC 调用失败不能只丢掉 error。真实场景中，你要区分是网络中断、服务无响应、还是业务逻辑拒绝——这些影响 LB 决策：
-
rpc.Client.Call返回io.EOF或connection refused，说明后端已不可达，应临时剔除该节点 - 设置 per-call 超时：用
context.WithTimeout包裹client.Go，避免一个慢节点拖垮整个客户端 - 不要让 LB 层吞掉底层连接错误，否则健康状态永远不更新
负载均衡不是加个循环就完事，核心是「感知失败」+「快速隔离」+「平滑恢复」。标准库没提供这些能力，得靠你在客户端里小心编织逻辑。
