17370845950

实现RPC负载均衡需在客户端控制连接目标，通过服务发现获取节点列表，结合轮询或随机策略选择后端，封装统一客户端支持重试与熔断，并推荐升级至gRPC以利用其内置负载均衡与健康检查机制。

Go 语言标准库的 net/rpc 本身不提供负载均衡能力，要实现 RPC 请求的负载均衡，关键在于**在客户端侧控制连接目标**，把服务发现、健康检查和路由策略做在调用前。下面给出几种实用、可落地的方案。

基于服务发现 + 随机/轮询选择后端

这是最常见也最轻量的方式。前提是多个 RPC 服务实例已注册到 Consul、etcd 或自建 registry 中。

• 客户端启动时从服务发现中心拉取可用节点列表（如 ["10.0.1.10:8080", "10.0.1.11:8080"]）
• 每次发起 RPC 前，用轮询（Round Robin）或随机（Random）策略选一个地址
• 使用 rpc.DialHTTP("tcp", addr) 或 jsonrpc.NewClient 连接并调用
• 建议搭配简易健康检查：失败 3 次自动剔除该节点，5 秒后尝试恢复

封装统一的 RPC 客户端代理

避免每个业务都重复写选节点逻辑，推荐封装一个 LoadBalancedClient：

• 内部维护节点列表、当前索引（轮询）、失败计数器（熔断）
• 暴露 Call(serviceMethod string, args, reply interface{}) error 方法
• 调用时自动重试（最多 2 次），跳过已标记为不可用的节点
• 支持配置策略：roundrobin / random / leastconn（需主动上报连接数）

利用 gRPC 替代原生 net/rpc（推荐升级路径）

如果项目允许演进，强烈建议迁移到 gRPC。它原生支持多负载均衡策略：

• 内置 round_robin、pick_first，通过 grpc.WithBalancerName("round_robin") 启用
• 配合 grpc.Resolver 接口，可对接 etcd/Consul 实现动态服务发现
• 天然支持连接复用、超时控制、流控、TLS，比 net/rpc 更健壮易维护
• Go 官方维护、生态完善，protobuf 接口定义也更利于跨语言协作

简单场景：DNS 轮询 + TCP 层负载均衡

对小规模或测试环境，可以绕过代码层负载均衡：

• 用域名（如 rpc-svc.internal）指向多个 A 记录（各服务 IP）
• 客户端直接 Dial 该域名，依赖系统 DNS 缓存实现粗粒度轮询
• 更进一步，前端加一层 Nginx 或 HAProxy，做 TCP 代理 + 健康探测
• 优点是零代码改动；缺点是缺乏细粒度控制（比如按方法分流、权重、熔断）

基本上就这些。核心思路是：RPC 负载均衡不在服务端做，而在客户端做决策；越早把服务发现和路由逻辑抽象出来，后续扩展性越强。不复杂但容易忽略的是健康状态同步和失败降级——哪怕只加一行日志记录哪台挂了，也能省去很多线上排查时间。