Go客户端负载均衡需自定义http.RoundTripper，在RoundTrip中集成服务发现、健康检查与节点选择逻辑，复用http.Transport连接池，动态更新endpoints并调用CloseIdleConnections避免打到下线节点。
Go 客户端负载均衡的核心是替代默认的 http.RoundTripper
Go 标准库的 http.Client 默认使用 http.DefaultTransport，它内部用单个连接池发请求，不感知后端多个实例。要实现客户端负载均衡，必须自定义 RoundTripper，在每次请求前动态选择目标地址。
关键不是“加一个轮询函数”，而是把服务发现、健康检查、选节点逻辑封装进 RoundTrip(*http.Request) (*http.Response, error) 方法里。否则只是静态配置，无法应对节点上下线。
- 不要直接修改
req.URL.Host后复用原 transport——这会绕过 DNS 缓存与连接复用策略，引发连接泄漏 - 推荐组合已有 transport：用
&http.Transport{}作为底层，只重写RoundTrip做 host 注入 - 若用 gRPC，对应的是自定义
grpc.WithBalancerName或实现balancer.Balancer接口，而非 HTTP 层逻辑
用 net/http/httputil 实现简单轮询或随机转发
快速验证可用性时，可基于 httputil.NewSingleHostReverseProxy 改造，但注意它本身不支持多 backend。需手动维护 endpoint 列表，并在 RoundTrip 中替换 req.URL 的 host/port。
以下是最简可行示例（无健康检查、无权重）：
立即学习“go语言免费学习笔记（深入）”；
type LoadBalanceTransport struct {
endpoints []string // e.g. ["http://10.0.1.10:8080", "http://10.0.1.11:8080"]
mu sync.RWMutex
idx int
}
func (t *LoadBalanceTransport) RoundTrip(req *http.Request) (*http.Response, error) {
t.mu.Lock()
target := t.endpoints[t.idx%len(t.endpoints)]
t.idx++
t.mu.Unlock()
u, _ := url.Parse(target)
proxy := httputil.NewSingleHostReverseProxy(u)
// 注意：此处需复制原始 req.Header，否则 Host 被覆盖后可能出错
req.Host = u.Host
req.URL.Scheme = u.Scheme
req.URL.Host = u.Host
req.URL.Path = ""
req.URL.RawQuery = ""
return proxy.Transport.RoundTrip(req)
}
-
httputil.NewSingleHostReverseProxy内部已处理连接复用和超时，复用它比手写 dial 更安全 - 必须重设
req.URL.Path和RawQuery，否则会拼接两次路径（如http://a/b/c+/api/x→/b/c/api/x） - 真实场景中应避免锁全局
idx，改用原子操作或一致性哈希减少竞争
集成服务发现（如 etcd / Consul）时注意 watch 生命周期
客户端负载均衡若依赖外部注册中心，endpoints 列表不能只初始化一次。必须监听变更事件并热更新，否则节点下线后仍会转发请求。
常见错误是：启动时拉一次服务列表，之后完全不管变化。正确做法是启动 goroutine 持续 watch，并安全替换 transport 内部 endpoint 切片。
- etcd 使用
clientv3.Watcher监听/services/myapp/前缀，收到PUT/DELETE事件后更新内存列表 - 更新 endpoint 切片时，用
atomic.StorePointer存储指向新切片的指针，避免读写竞争 - watch 连接断开时要自动重连，否则后续变更永远收不到——很多 SDK 默认不重试
为什么不用第三方库如 go-resty 或 gorilla/handlers？
它们不提供真正的客户端负载均衡能力。go-resty 的 SetHostURL 是静态设置，gorilla/handlers.ProxyHeaders 只是透传 header。真正需要的是在每次 RoundTrip 前决策目标地址，而这些库没暴露 transport 层钩子。
如果你已在用 gRPC-Go，优先走官方 balancer 体系；如果是纯 HTTP，建议直接封装 http.Transport，而不是套一层 resty 再去 patch 它的 client。
- resty 的
SetRetryCount和负载无关，它只控制失败后重试次数，不决定重试发给谁 - 某些 “load balancing” 示例实际只是随机选 host 后调
http.Get，这种写法无法复用连接池，高并发下 fd 耗尽风险极高 - 真正稳定的方案必含：连接池复用 + 动态 endpoint 更新 + 失败熔断（比如连续 3 次 dial timeout 就临时剔除该节点）
transport.CloseIdleConnections() 并配合 MaxIdleConnsPerHost 控制，才能让旧连接自然淘汰。 
