Go客户端轮询负载需自定义http.RoundTripper，用atomic维护索引并动态选后端；服务端应依赖外部LB或Service Mesh；gRPC-Go需显式配置service config启用round_robin。
Go 本身不内置负载均衡器，但可通过组合 net/http、http.RoundTripper 和第三方库（如 gorilla/health 或自定义逻辑）实现客户端侧微服务负载策略；服务端侧需依赖外部 LB（如 Nginx、Envoy）或 Service Mesh（如 Istio）。
如何用 http.RoundTripper 实现轮询（Round Robin）客户端负载
这是最常见、最可控的客户端负载方式。核心是复用 http.Transport 并在请求前动态选择后端地址。
- 不能直接修改
http.Client的默认Transport来做轮询——它不保存状态，每次请求都独立 - 必须自定义
RoundTripper，内部维护一个可原子递增的索引（如atomic.Uint64） - 后端列表应支持健康检查，否则挂掉的节点仍会被轮到；简单场景可先忽略，复杂场景建议搭配
sync.Map缓存失败标记 - 注意 DNS 缓存：若用域名（如
svc-a.default.svc.cluster.local），http.Transport默认会缓存解析结果，导致扩缩容后不生效；可设transport.DialContext+ 自定义 DNS 解析，或使用 IP 直连
type RoundRobinTransport struct {
backends []string
mu sync.RWMutex
index uint64
}
func (r *RoundRobinTransport) RoundTrip(req *http.Request) (*http.Response, error) {
backend := r.backends[atomic.AddUint64(&r.index, 1)%uint64(len(r.backends))]
req.URL.Scheme = "http"
req.URL.Host = backend
return http.DefaultTransport.RoundTrip(req)
}
为什么不用 net/http/httputil.NewSingleHostReverseProxy 做服务端负载
它本质是反向代理，不是负载均衡器；NewSingleHostReverseProxy 只支持单 host，想多节点必须自己封装 Director 函数并配合 sync/atomic 实现调度逻辑。
- 它的
Director是每次请求调用一次的函数，适合做 header 改写或路径重写，不适合做带状态的负载决策 - 没有内置超时熔断、权重、一致性哈希等策略；加这些就得自己补全
RoundTripper、错误重试、连接池管理 - 生产环境不建议用它承载高并发 LB 流量——它不复用底层连接池配置，容易耗尽文件描述符
- 如果你只是临时调试或 mock 多实例，可以快速起一个，但别上线
gRPC-Go 中如何配置客户端负载策略
gRPC-Go 从 v1.27+ 开始弃用内置负载均衡插件机制（如 round_robin），改用 Resolver + Picker 组合，且默认不启用任何策略，必须显式配置。
立即学习“go语言免费学习笔记（深入）”；
- 不设置
WithBalancerName（已废弃）或WithDefaultServiceConfig，客户端会直连第一个解析出的地址，无负载效果 - 要启用轮询，需传入 service config JSON：
{"loadBalancingConfig": [{"round_robin": {}}]} - 如果后端是 Kubernetes Headless Service，DNS 解析返回多个 A 记录，gRPC 默认支持 SRV 记录和 DNS 解析结果轮询，但前提是 resolver 实现支持（
dns:///svc-a.default.svc.cluster.local:8080） - 权重、最少连接数等策略需自己实现
balancer.Picker接口，且要注意线程安全——Pick方法会被多 goroutine 并发调用
conn, err := grpc.Dial("dns:///svc-a.default.svc.cluster.local:8080",
grpc.WithTransportCredentials(insecure.NewCredentials()),
grpc.WithDefaultServiceConfig(`{"loadBalancingConfig": [{"round_robin": {}}]}`),
)
容易被忽略的点：健康探测与连接复用冲突
很多开发者在 RoundTripper 中加入 HTTP 健康检查（如定期 GET /health），却没意识到 http.Transport 的 MaxIdleConnsPerHost 会导致“假存活”：即使后端已宕机，连接池里还留着旧连接，后续请求仍会复用并失败。
- 健康检查必须和连接池联动：比如用
transport.RegisterProtocol替换默认 HTTP 协议处理，或监听transport.IdleConnTimeout事件主动驱逐异常 host - 更稳妥的做法是把健康检查下沉到服务发现层（如 Consul、Nacos），让 Go 客户端只消费最终健康的 endpoint 列表
- 不要在
RoundTrip内同步做健康探测——会拖慢所有请求；应异步更新，用读写锁保护 backend 列表
