因为http.RoundTripper不维护节点状态、无健康检查与权重支持，无法实现动态故障转移；真正负载均衡需结合服务发现、运行时热更新节点列表、每次请求实时选节点，并封装复用连接池。
Go 微服务中为什么不能只靠 http.RoundTripper 做负载均衡
因为标准库的 http.RoundTripper 本身不维护后端节点状态，也不支持健康检查、权重、重试或连接复用策略。直接用它做“轮询”只是简单循环，一旦某个服务实例宕机，请求会持续失败直到超时，客户端无法感知故障转移。
真正可用的负载均衡必须结合服务发现（如 Consul、Nacos、etcd）或静态节点列表，并在每次请求前动态选节点。常见错误是把负载逻辑写死在 RoundTripper 初始化里，导致节点列表无法热更新。
- 节点列表需支持运行时增删（例如监听 etcd watch 事件）
- 选择算法（如加权轮询、最少连接）应在每次
RoundTrip()调用时实时计算 - 必须封装连接池（
&http.Transport{}）并复用底层 TCP 连接，否则高并发下 FD 耗尽
用 gorilla/roundtrip 或自定义 http.RoundTripper 实现可插拔均衡器
推荐用轻量方案：不引入大框架（如 go-micro），而是自己实现一个带状态的 RoundTripper。核心是把节点管理与路由分离——节点由独立结构体维护，RoundTripper 只负责调用 Select() 拿到目标 *url.URL 后代理请求。
以下是一个最小可行示例，支持轮询 + 健康标记：
立即学习“go语言免费学习笔记（深入）”；
type Balancer struct {
nodes []*Node
mu sync.RWMutex
cursor uint64
}
<p>type Node struct {
URL *url.URL
Healthy bool
Failures int
}</p><p>func (b <em>Balancer) Select() </em>url.URL {
b.mu.RLock()
defer b.mu.RUnlock()
if len(b.nodes) == 0 {
return nil
}
for i := 0; i < len(b.nodes); i++ {
idx := int((atomic.AddUint64(&b.cursor, 1) - 1) % uint64(len(b.nodes)))
if b.nodes[idx].Healthy {
return b.nodes[idx].URL
}
}
return nil // 全挂了，由上层决定降级或报错
}</p><p>func (b <em>Balancer) RoundTrip(req </em>http.Request) (*http.Response, error) {
u := b.Select()
if u == nil {
return nil, errors.New("no healthy node available")
}
// 克隆 req，改写 URL 和 Host
req2 := req.Clone(req.Context())
req2.URL = &url.URL{
Scheme: u.Scheme,
Opaque: u.Opaque,
User: u.User,
Host: u.Host,
Path: req.URL.Path,
RawQuery: req.URL.RawQuery,
Fragment: req.URL.Fragment,
}
req2.Host = u.Host
return http.DefaultTransport.RoundTrip(req2)
}gRPC 场景下必须用 grpc.WithBalancerName 配合 balancer.Builder
HTTP 负载均衡可以自己封装，但 gRPC 的连接管理、流控、重连都深度耦合在 balancer 系统里。硬套 HTTP 方式会导致连接泄漏、Stream 意外关闭、metadata 丢失等问题。
正确做法是注册自定义 balancer.Builder，并在 Build() 中返回实现了 balancer.Balancer 接口的实例。关键点：
-
UpdateClientConnState()是服务发现变更的唯一入口，必须在这里触发节点刷新 - 每个
SubConn对应一个后端地址，要主动调用cc.Connect()触发建连 - 不要在
HandleResolvedAddrs()里直接拨号，那是异步回调，应只更新内部节点列表
如果你用的是 etcd 做服务发现，建议直接用 go.etcd.io/etcd/client/v3/naming/endpoints 提供的 Resolver，再配合官方 round_robin 或 least_request balancer，比手写更稳。
生产环境绕不开的三个坑
很多团队在压测或上线后才发现问题，往往卡在这三点：
-
http.Transport.MaxIdleConnsPerHost默认是 2，微服务间调用频繁时极易出现 “connection refused” 或延迟毛刺，建议设为100或更高 - 服务发现节点变更后，旧连接不会自动断开，需手动调用
transport.CloseIdleConnections()清理；但频繁调用会影响性能，推荐加定时器（如 30s 一次）+ 变更事件双触发 - HTTP/2 下，单个 TCP 连接复用多个 stream，如果某后端节点崩溃，整个连接会被标记为 broken，但 Go 的
http.Transport不会主动剔除该连接，需要配合GetConn/GotConn钩子做连接级健康检测
最麻烦的其实是故障传播：A 服务调用 B，B 调用 C，C 挂了 → B 的连接池塞满 → A 请求全卡住。这需要在每一层都配置合理的超时、熔断和限流，而不仅是“加个负载均衡器”就能解决。
