Go标准库net/http不提供负载均衡能力，需在应用外部署Nginx等LB或在程序内实现客户端侧轮询等策略，gRPC则可通过官方balancer支持round_robin。
Go 标准库 net/http 本身不提供负载均衡能力
很多人误以为用 http.ServeMux 或 http.ListenAndServe 就能做服务端负载均衡，其实不是。Go 的 HTTP 服务器默认是单实例、单进程模型，它只负责接收请求并分发给 handler，不参与上游服务节点的健康检查、权重调度或故障转移。
真正需要负载均衡时，你面临两个选择：
- 在 Go 应用外部署独立负载均衡器（如 Nginx、HAProxy、Traefik、Envoy）
- 在 Go 程序内实现客户端侧负载均衡（即你的 Go 服务作为「客户端」，调用其他后端服务时做选节点逻辑）
后者常见于微服务间通信，比如用 http.Client 调用多个 user-service 实例时，需自己决定打到哪台。
用 roundrobin + sync/atomic 实现最简客户端 LB
如果你只需要轮询（Round Robin），且不追求一致性哈希或最小连接数，可以手动维护一个原子计数器来选节点：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
var counter uint64
func nextNode(nodes []string) string {
i := atomic.AddUint64(&counter, 1) % uint64(len(nodes))
return nodes[i]
}
注意点：
- 节点列表
nodes必须是只读或受控更新，否则并发读写会出错 - 这个方案无健康检查——某个节点挂了，请求仍会发过去，直到超时
- 适合开发/测试环境快速验证，生产环境建议用成熟库
用 google.golang.org/grpc/balancer/roundrobin 做 gRPC LB
如果你用的是 gRPC（而非 HTTP），Go 官方 gRPC 库已内置几种负载均衡策略，roundrobin 是默认启用的（只要你在 Dial 时指定 WithBalancerName("round_robin")）：
conn, err := grpc.Dial(
"dns:///my-service.example.com",
grpc.WithTransportCredentials(insecure.NewCredentials()),
grpc.WithBalancerName("round_robin"),
)
关键前提：
- 必须使用 DNS 解析（
dns:///scheme），否则 balancer 不生效 - 后端节点需通过 SRV 记录或 DNS A 记录暴露，gRPC 会自动监听变更
- HTTP/1.1 服务无法复用这套机制；它只对 gRPC over HTTP/2 生效
别跳过健康检查和重试逻辑
真实环境中，单纯“选节点”只是第一步。你大概率还需要：
- 定期对每个后端发起
HEAD /health探活，并缓存结果（避免每次请求都检查） - 在
http.Client中设置Timeout和MaxIdleConnsPerHost，防止慢节点拖垮整个连接池 - 对 5xx 或连接失败的请求做有限重试（推荐用
backoff.Retry或自定义指数退避）
这些逻辑加起来就接近一个轻量级 LB SDK 了。直接手写容易漏边界情况，比如 DNS 缓存未刷新、panic 未 recover、goroutine 泄漏——除非业务极其简单，否则建议评估 go-resty + 自定义 transport，或引入 kitex/kratos 这类带 LB 插件的框架。
