绝大多数情况下不需要自己实现负载均衡，因gRPC-Go等框架已内置支持；需配置resolver和balancer，推荐用WithDefaultServiceConfig；自定义仅限私有注册中心或特殊策略场景。
Go 微服务客户端要不要自己实现负载均衡
绝大多数情况下，不需要自己写负载均衡逻辑。Go 标准库 net/http 本身不提供客户端侧服务发现与负载均衡能力；但主流微服务框架（如 gRPC-Go、Kit、Go-Micro）或服务网格（如 Istio）已将这一层抽象掉。直接手撸轮询/随机/一致性哈希，往往掩盖了真实问题：服务注册中心没接入、健康检查缺失、DNS 缓存未控制、连接复用被忽略。
gRPC-Go 客户端负载均衡怎么开箱即用
gRPC-Go v1.27+ 原生支持客户端负载均衡，但必须满足两个前提：resolver 提供服务实例列表 + balancer 实现选择策略。默认只启用 passthrough（单地址直连），要启用真实 LB，需显式配置：
- 使用
dns:///service-name或自定义resolver.Builder接入 Consul/Etcd/Nacos - 通过
grpc.WithBalancerName("round_robin")指定算法（支持"round_robin"、"least_request"、"pick_first"） -
round_robin是唯一稳定内置的算法；least_request仅实验性支持，且需配合grpclb协议
conn, err := grpc.Dial("dns:///user-service",
grpc.WithTransportCredentials(insecure.NewCredentials()),
grpc.WithDefaultServiceConfig(`{"loadBalancingConfig": [{"round_robin": {}}]}`),
)
注意：WithDefaultServiceConfig 比 WithBalancerName 更推荐——它走的是 gRPC 的 service config 机制，兼容服务端下发策略。
自定义负载均衡器何时必须写，怎么写才不出错
只有当你要对接私有注册中心（比如直连 ZooKeeper 节点列表）、或需要特殊策略（如按机房路由、权重动态更新、熔断后自动剔除）时，才需实现 balancer.Balancer 接口。常见翻车点：
立即学习“go语言免费学习笔记（深入）”；
- 忘记在
UpdateClientConnState中调用cc.UpdateState()，导致连接池不刷新 - 在
Pick方法里做同步 HTTP 请求查权重，阻塞 gRPC 调用链 - 未处理
SubConn的ConnectivityState变化（如TRANSIENT_FAILURE后未重试或降权） - 把实例列表存在结构体字段里却没加锁，引发并发读写 panic
最简 round-robin 示例只需维护一个原子计数器：
type rrBalancer struct {
mu sync.RWMutex
conns []balancer.SubConn
idx uint64
}
func (b *rrBalancer) Pick(info balancer.PickInfo) (balancer.PickResult, error) {
b.mu.RLock()
defer b.mu.RUnlock()
if len(b.conns) == 0 {
return balancer.PickResult{}, balancer.ErrNoSubConnAvailable
}
i := int(atomic.AddUint64(&b.idx, 1) % uint64(len(b.conns)))
return balancer.PickResult{SubConn: b.conns[i]}, nil
}
HTTP 客户端负载均衡绕不开的三个坑
如果你用 http.Client 调用 REST 微服务（而非 gRPC），那负载均衡完全得自己兜底。这时最容易忽视的是：
- DNS 缓存：Go 的
net.Resolver默认缓存 5 秒，但http.Transport不感知 DNS 变更，需配transport.DialContext+ 自定义 resolver 控制 TTL - 连接复用失效：不同后端地址共用同一个
http.Transport，但MaxIdleConnsPerHost是按 host 计的，若用 IP 轮询，每个 IP 都算独立 host，连接池打不满 - 健康探测脱节：轮到一个挂掉的实例时，
http.Client默认只超时失败，不会自动标记为不可用；得自己加sync.Map存活状态 + 异步探活 goroutine
简单起见，优先考虑用 github.com/hashicorp/go-retryablehttp 封装，并在 CheckRetry 回调里判断 HTTP 状态码 + 网络错误类型，触发临时摘除。
真正难的不是选算法，而是让“可用实例列表”实时、准确、低延迟地抵达客户端——注册中心长连接是否稳、心跳间隔是否合理、客户端缓存是否及时失效，这些比 round_robin 还是 consistent_hash 重要得多。
