go微服务负载均衡应优先依赖基础设施而非手写逻辑，因手写难以兼顾健康探测、优雅下线、连接池隔离和指标暴露等能力。
Go 微服务中如何选择和实现负载均衡策略
Go 本身不内置服务发现或负载均衡逻辑，实际负载均衡发生在客户端（如 grpc-go 的 Resolver 和 Balancer）、反向代理（如 Nginx、Envoy）或服务网格（如 Istio）层。你在 Go 代码里直接“实现算法”通常只出现在自研客户端负载均衡器场景，比如用 net/http 轮询调用多个后端实例时。
- 轮询（Round Robin）适合无状态、性能均一的服务，但无法感知节点健康或负载
- 加权轮询（Weighted RR）需配合服务注册中心下发权重，
etcd或consul的 KV 可存权重配置 - 最少连接（Least Connections）在 Go 中需维护每个后端的活跃连接数，注意并发读写要加
sync.Map或sync.RWMutex - 一致性哈希（Consistent Hashing）适合缓存类服务，可用
github.com/cespare/xxhash/v2+github.com/hashicorp/go-multierror实现环结构，避免节点增减导致大量 key 迁移
gRPC-Go 中启用内置负载均衡器的正确姿势
gRPC-Go v1.27+ 默认禁用客户端负载均衡，必须显式配置 resolver 和 balancer，否则所有请求都打到第一个解析出的地址。
- 使用
dns:///service.example.com作为目标 URL 时，需注册dnsresolver：确保已导入_ "google.golang.org/grpc/resolver/dns" - 启用
round_robin策略需传入grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy":"round_robin"}`) - 若用
passthroughresolver（如passthrough:///10.0.1.1:8080,10.0.1.2:8080），必须手动指定balancer，否则会 panic：错误信息类似"no load balancing policy configured" - 自定义 balancer 需实现
balancer.Balancer接口，注意UpdateClientConnState触发时机与Resolver返回结果强相关
HTTP 客户端做简单负载均衡时的常见陷阱
用 http.Client + 自定义 RoundTripper 做轮询，看似简单，但容易忽略连接复用、超时传播和故障剔除。
- 不要在每次请求时 new 一个
http.Client，应复用并设置Transport.MaxIdleConnsPerHost = 100 - 轮询逻辑不能放在
RoundTrip内部做锁竞争，建议用原子计数器atomic.AddUint64(&idx, 1)+ 取模 - 遇到
connection refused或 HTTP 5xx，应临时将该 endpoint 标记为“退避”，避免雪崩；可用time.Now().Add(30 * time.Second)存入sync.Map - 别忘了处理
context.DeadlineExceeded：它会中断正在 dial 的连接，但不会自动触发故障剔除，需在RoundTrip错误分支里显式处理
何时该放弃手写负载均衡，转而依赖基础设施
除非你有极特殊调度需求（如按请求 header 中的 region 字段路由），否则不建议在业务代码里维护负载均衡逻辑。
立即学习“go语言免费学习笔记（深入）”；
- Kubernetes Service 的
ClusterIP已内置 iptables/ipvs 轮询，够用就别绕过 - Service Mesh（如 Linkerd）接管了 mTLS、重试、熔断和分布式追踪，手写 balancer 很难对齐这些能力
- 云厂商 SLB（如 AWS ALB、阿里云 NLB）支持基于权重、健康检查、最小空闲连接等策略，且可观测性完备
- 最隐蔽的问题是：手写逻辑很难正确处理 DNS 缓存 TTL 变更——
net.Resolver默认不刷新，需要自己定时LookupHost并 diff
真正难的不是写一个轮询函数，而是让整个链路具备健康探测、优雅下线、连接池隔离和指标暴露能力。这些在 Envoy 或 gRPC 的 xDS 协议里已有成熟设计，重复造轮子反而增加运维负担。
