Go标准库net/rpc客户端需自行实现轮询负载均衡，通过RRClient封装rpc.Client切片与原子计数器，调用时取模选节点并跳过失败实例；不可用HTTP反向代理因协议不兼容，gRPC更优因其原生支持轮询及服务发现。
Go 标准库的 net/rpc 本身不提供负载均衡能力，必须在客户端侧自行实现分发逻辑；服务端仍是无状态的多个独立 RPC 实例，由客户端决定调用哪个地址。
如何用 Go 客户端实现轮询（Round Robin）RPC 调用
最常用也最容易控制的策略。关键不是改服务端，而是封装一个带连接池和计数器的客户端代理。
- 维护一个
[]*rpc.Client切片，每个元素对应一个服务实例的*rpc.Client - 用原子计数器（
atomic.AddUint64(&counter, 1)）做简单轮询索引 - 每次调用前检查
client.Go是否返回非 nil error，失败则跳过该节点（需配合重试或健康标记） - 不要复用
rpc.Client跨 goroutine —— 它不是并发安全的，但可被多个 goroutine 同时调用方法（内部有锁），所以通常直接复用即可
type RRClient struct {
clients []*rpc.Client
counter uint64
}
func (c *RRClient) Call(serviceMethod string, args interface{}, reply interface{}) error {
idx := atomic.AddUint64(&c.counter, 1) % uint64(len(c.clients))
client := c.clients[idx]
return client.Call(serviceMethod, args, reply)
}
为什么不能直接用 http.Transport 或反向代理做 RPC 负载？
Go 的 net/rpc 默认基于 TCP + 自定义二进制协议（或 JSON），不走 HTTP；即使你用 rpc.ServeHTTP 暴露在 HTTP 上，其请求体是 application/json 但结构不符合 REST，标准 HTTP 负载均衡器（如 Nginx、Traefik）无法解析 method 名与 service 名，会直接转发失败或 404。
- Nginx 的
upstream只能做 TCP 层转发，但 RPC 连接有粘性（一次连接多次调用），容易导致 session 不一致 - 若强行用 HTTP 模式，必须统一用
rpc.JSONRPCClient，且服务端要注册为http.HandlerFunc，此时仍需客户端识别错误并切换 endpoint - 真正可行的“透明”负载层只有自研 TCP 代理（如基于
golang.org/x/net/proxy做连接转发），但复杂度远超客户端均衡
使用 grpc-go 替代标准 net/rpc 的负载优势
如果你能升级协议，grpc-go 原生支持多种负载均衡策略，且由底层 balancer 接口驱动，无需手动管理连接列表。
立即学习“go语言免费学习笔记（深入）”；
- 默认使用
pick_first，但可通过grpc.WithBalancerName("round_robin")启用轮询 - 服务发现可对接
etcd、consul或 DNS：只需传入resolver.Builder，gRPC 自动监听变更并更新 subconn - 连接健康检测由
health check插件或底层 TCP keepalive 驱动，失败自动摘除节点 - 注意：gRPC 的负载发生在 stream 级别，不是单次 RPC 调用级别；短连接场景下效果接近轮询，长连接则更倾向复用
客户端重试 + 熔断时，负载逻辑容易出错的关键点
轮询或随机选节点后若失败，重试时不重置索引，会导致连续打到同一个坏节点；熔断器若没绑定到具体 endpoint，可能误熔整个集群。
- 重试应重新计算目标节点（例如再调一次
next()），而不是原地重试 - 熔断器建议按 endpoint 维度隔离，例如用
github.com/sony/gobreaker的 map[string]*gobreaker.CircuitBreaker - 避免在
Call方法里做同步 DNS 查询或服务发现刷新——这会阻塞所有调用；应另起 goroutine 定期更新clients列表，并用sync.RWMutex保护读写 - 日志中务必记录实际调用的地址（如
client.URL），否则排查时无法区分是负载逻辑问题还是某个实例故障
负载均衡的复杂性不在算法本身，而在于失败转移、服务发现时效性、连接生命周期与业务语义的耦合；标准 net/rpc 客户端均衡看似简单，但生产环境必须补全健康探测、配置热更新和指标暴露，否则只是把问题从服务端推到了客户端。
