17370845950

Go原生net/rpc不支持负载均衡，需结合客户端选节点逻辑与服务端注册发现机制实现；核心是将节点选择前移到客户端，支持轮询、随机、最少连接、加权等策略，并依赖etcd等注册中心实现服务发现与健康探测。

Go 语言原生 net/rpc 不支持负载均衡，但通过组合客户端选节点逻辑 + 服务端注册/发现机制，可以构建轻量、可控的 RPC 负载均衡系统。核心在于把“找哪个服务实例处理请求”这件事，从服务端（如 Nginx）前移到客户端或中间协调层，提升灵活性与实时性。

客户端负载均衡：自己选服务节点

客户端维护一份可用服务地址列表（例如从 Consul/Etcd/ZooKeeper 拉取，或静态配置），每次调用前按策略选择一个节点发起 RPC 连接。

• 简单轮询（Round Robin）：维护一个原子计数器，每次取模递增，适合各节点性能均等的场景
• 随机（Random）：开销最低，适合节点数量稳定、故障率低的集群
• 最少连接（Least Connections）：需服务端上报当前并发请求数（如通过健康检查接口），客户端据此选择压力最小的节点
• 加权策略：为不同机器配置权重（如 CPU 核心数、内存大小），按比例分配流量；可结合轮询或随机实现

示例片段（轮询）：

var ( addrs = []string{"192.168.1.10:8080", "192.168.1.11:8080"} mu sync.RWMutex idx uint64 ) func nextAddr() string { mu.Lock() defer mu.Unlock() addr := addrs[idx%uint64(len(addrs))] idx++ return addr }

服务端注册与健康探测：让客户端“知道谁活着”

服务启动时向注册中心（如 etcd）写入自身地址和元数据（版本、权重、标签），并定期续租（TTL）。客户端监听变更或定时拉取，自动剔除失联节点。

• 使用 clientv3（etcd 官方 Go SDK）注册：写入 /services/rpc-service/192.168.1.10:8080，设置 TTL=30s
• 健康检查建议采用 TCP 心跳或轻量 HTTP 探针（如 /health），避免阻塞 RPC 主流程
• 注册时可附加自定义字段，如 {"weight": 10, "zone": "shanghai"}，供客户端做路由决策

基于 gRPC 的进阶方案（推荐）

若项目允许升级协议，gRPC 原生支持客户端负载均衡插件（balancer.Builder），比原生 net/rpc 更成熟：

• 使用 grpc.WithBalancerName("round_robin") 启用内置策略
• 自定义 Resolver 实现服务发现（对接 etcd/Consul），动态更新后端地址列表
• 配合 grpc.WithKeepaliveParams 和重试策略，提升弱网下稳定性

相比手撸 net/rpc 均衡逻辑，gRPC 生态更完善、TLS/流控/超时控制更精细，中小规模服务推荐优先采用。

关键细节提醒

• 连接复用：每个服务地址应复用 *rpc.Client 或 gRPC *grpc.ClientConn，避免频繁建连开销
• 失败转移（Failover）：单次调用失败后，不应立即报错，而应尝试列表中下一个节点（需控制重试次数，防止雪崩）
• 一致性哈希（可选）：对 key（如用户 ID）做哈希后固定路由，适合带状态或缓存亲和性的场景
• 避免单点注册中心：etcd/Consul 集群部署，客户端配置多个 endpoint，防止单点故障导致全量服务不可见

基本上就这些。不复杂但容易忽略的是健康状态同步延迟和连接池管理——这两项做好，负载均衡才真正可靠。