Golang微服务负载均衡必须由客户端主动实现，因http.Client不维护实例列表且无健康感知；应使用go-kit/sd+lb构建可插拔抽象层，或gRPC原生resolver/balancer机制，并独立处理健康检查与缓存更新。
Golang微服务的负载均衡必须由客户端主动实现，不能靠http.Client或硬编码地址“自动分发”——它压根不维护实例列表，也不感知健康状态。
为什么不能直接用http.Get或http.Client.Do做负载均衡
常见错误是写一个循环调用http.Get("http://10.0.1.10:8080/api")，再手动换地址。这会导致：
- 每次请求都要重新拼URL、新建连接，无法复用
http.Transport连接池 - 节点宕机后仍会持续发请求，直到超时才失败，放大错误
- 无法集成健康检查、权重、重试、指标打点等生产必需能力
- 策略变更（比如从轮询切到最少连接）要改所有业务调用点，不可维护
真正需要的是一个**可插拔的客户端抽象层**：它知道有哪些健康实例、按什么规则选、失败后怎么fallback、调用完怎么记录延迟。
用go-kit/sd + lb搭出最小可行负载均衡器
这是Go生态中成熟、轻量、符合分层思想的方案，不用自己写轮询计数器或监听逻辑。核心三步：
立即学习“go语言免费学习笔记（深入）”；
-
sd.Instancer负责从Consul/Etcd/静态配置拉取并监听实例变化（自动剔除不健康节点） -
lb.Balancer封装选择策略（默认RoundRobin，也可换Random或自定义） -
lb.Opportunist包装器让失败请求自动重试下一个节点（不是每次都换，而是首次失败才fallback）
示例代码片段（非完整启动）：
Product Opportunity Analyzer
下载
从电商评论中挖掘产品机会，自动抓取1‑3星评论并使用Map‑Reduce提取痛点，生成产品洞察报告。用户发送亚马逊商品链接时触发该技能。
instancer := sd.NewStaticInstancer([]string{
"http://10.0.1.10:8080",
"http://10.0.1.11:8080",
}, nil)
balancer := lb.NewRoundRobin(instancer)
endpoint := httptransport.NewClient(
"POST",
lb.NewOpportunist(balancer), // ← 关键：带fallback的包装
encodeRequest,
decodeResponse,
).Endpoint()
后续调用endpoint(ctx, req)就自动完成发现→选节点→发请求→失败重试→记录日志全流程。
gRPC场景下优先走resolver + balancer原生链路
如果你用gRPC通信，别绕路封装HTTP客户端——gRPC Go SDK已内置完整支持：
- 实现
grpc.Resolver从Consul/Etcd读取Address列表，并监听变更 - 注册自定义
grpc.Balancer（如加权最小连接数），或直接启用内置"round_robin" - Dial时传入
grpc.WithResolvers(myResolver)，框架自动解析+负载
注意两个易错点：
- 目标格式必须是
"dns:///user-svc"或"etcd:///user-svc"，不能是"10.0.1.10:8080"，否则绕过resolver - 默认
pick_first策略只连第一个节点，要显式设grpc.WithDefaultServiceConfig(`{"loadBalancingConfig": [{"round_robin":{}}]}`)
健康检查和缓存更新必须独立于请求路径
很多团队把健康探测塞进第一次请求里（“连不上就换一个”），这是反模式：
- 首请求必然慢，用户体验差
- 高频服务下大量无效探测冲击下游
- 无法区分网络抖动和真实故障
正确做法是：
- 启动后台goroutine，对每个实例定期发
HEAD /health（带context.WithTimeout） - 连续失败3次后调用
instancer.Remove()，恢复后自动Add() - 本地缓存实例列表，所有
Next()操作都基于缓存读，避免每次查Consul
最常被忽略的是缓存更新时机：当Consul返回新列表时，应原子替换整个切片，而不是逐个Add/Remove——否则并发调用可能看到中间态空列表。
