Go微服务中不能直接用http.Client做负载均衡，因其不维护实例列表、不感知健康状态与权重变化，无法自动轮询或多节点重试；需借助go-kit/sd等组件实现服务发现与动态负载均衡。
Go 微服务中为什么不能直接用 http.Client 做负载均衡
因为 http.Client 本身不维护服务实例列表，也不感知健康状态或权重变化。你调用 client.Do(req) 时，目标地址是写死的或靠上层拼接，无法自动在多个 10.0.1.10:8080、10.0.1.11:8080 之间轮询或重试失败节点。
真正需要的是一个能动态管理后端节点、支持健康检查、可插拔策略的客户端抽象层。常见错误是把负载均衡逻辑硬编码进业务 HTTP 调用里，导致无法复用、难测试、升级策略要改一堆地方。
- 节点发现必须解耦：从 DNS、Consul、Nacos 或静态配置获取地址列表，不应和请求发送耦合
- 健康检查不能靠“第一次请求失败再换”：这会放大错误，应主动探活（如定期发
HEAD /health） - 策略切换需零重启：比如从
RoundRobin切到LeastConnections，不能重建整个 client 实例
用 go-kit/transport/http + sd 实现标准服务发现与负载均衡
这是 Go 生态中较成熟、符合微服务分层思想的做法：sd（service discovery）负责拉取/监听节点，transport/http 将其转化为可调用的 endpoint.Endpoint，中间由 lb 包提供策略。
关键不是自己写轮询算法，而是正确组装这些组件。下面是最小可行示例：
立即学习“go语言免费学习笔记（深入）”；
package main
import (
"context"
"time"
"github.com/go-kit/kit/sd"
"github.com/go-kit/kit/sd/lb"
httptransport "github.com/go-kit/kit/transport/http"
)
func main() {
// 1. 构建实例列表（这里用静态，实际可替换为 consul.Instancer）
instancer := sd.NewStaticInstancer([]string{
"http://10.0.1.10:8080",
"http://10.0.1.11:8080",
"http://10.0.1.12:8080",
}, nil)
// 2. 创建负载均衡器（默认 RoundRobin）
balancer := lb.NewRoundRobin(instancer)
// 3. 构造 endpoint（实际业务接口封装）
var endpoint httptransport.Endpoint
endpoint = httptransport.NewClient(
"POST",
lb.NewOpportunist(balancer), // 注意：这里传的是 balancer 的 opportunistic wrapper
encodeRequest,
decodeResponse,
).Endpoint()
// 后续用 endpoint(context.Background(), req) 发起带负载均衡的调用
}
注意 lb.NewOpportunist(balancer) —— 它不是每次调用都选新节点，而是在首次失败时才 fallback 到下一个实例，适合配合重试使用。若要严格轮询，应结合 lb.Retry 中间件。
grpc-go 场景下如何让 ClientConn 自动负载均衡
gRPC 官方不内置服务发现，但提供了 balancer 接口和 resolver 机制。你不能只写 grpc.Dial("10.0.1.10:9000")，而要注册自定义 resolver，让 gRPC 运行时能感知一组地址并交由 balancer 调度。
- resolver 负责“找谁”：监听 Consul 变更，返回
resolver.State{Addresses: []resolver.Address{...}} - balancer 负责“怎么连”：实现
Picker接口，决定每次Invoke()用哪个SubConn - 务必启用
WithDefaultServiceConfig(`{"loadBalancingPolicy":"round_robin"}`)，否则默认用p2c（仅限部分版本），且不生效
最简实践是直接使用社区封装好的包，例如 github.com/sercand/kuberesolver（适配 Kubernetes Service）或 github.com/grpc-ecosystem/go-grpc-middleware/resolver/dns（DNS SRV）。避免从零实现 Picker，除非你明确需要自定义权重或熔断逻辑。
自研简易轮询器时最容易漏掉的三个细节
如果项目轻量、依赖少，或只是临时验证，可以手写一个 RoundRobinBalancer。但以下三点不处理，上线后大概率出问题：
- 并发安全：
index字段必须用atomic.AddUint64(&b.index, 1)，而非b.index++—— 否则高并发下会跳过节点或重复选中 - 节点变更不感知：新增节点后，旧的
index % len(oldList)会越界 panic；需加锁同步更新列表和重置 index - 无健康隔离：某个节点连续超时 3 次，应临时剔除（加入 blacklist map），并在后台异步探测恢复，而不是等下次轮到它再失败一次
真正麻烦的从来不是“怎么选”，而是“什么时候不该选”和“选错了怎么兜底”。生产环境建议优先用 go-kit/sd 或 grpc-go 官方推荐链路，它们已覆盖连接复用、空闲驱逐、延迟统计等隐性需求。
