Go微服务负载均衡需构建服务发现、健康状态、策略选择闭环。须用watch监听实例变更并本地缓存，基于LastHealthyAt标记不健康节点，维护动态可用节点切片，失败节点熔断，高频扩缩容宜用least_request或加盐+虚拟节点的一致性哈希。
Go 微服务做负载均衡，不是配个库就完事——关键在于把 服务发现、节点健康状态 和 策略选择逻辑 三者串成闭环。硬编码地址或只用 gRPC 默认 round_robin 在生产环境大概率出问题。
怎么让客户端自动感知实例上下线？别靠定时拉取
很多团队一开始用 consul.Health().Service() 每 5 秒主动查一次，结果注册中心压力大、本地列表滞后、扩缩容延迟高。
- 改用
watch机制监听变更：Consul 用WatchPlan，etcd 用clientv3.Watcher，收到事件后原子替换本地sync.Map中的map[string]*Instance - 首次启动必须同步拉取兜底，避免 watch 延迟导致空列表
- 每个实例缓存
LastHealthyAt时间戳，超过 30 秒没心跳就标记为unhealthy，不参与调度 - 别在每次请求前临时查注册中心——所有决策必须基于本地缓存，否则 LB 本身就成了瓶颈
轮询（Round Robin）为什么并发下容易倾斜？用 atomic 要小心
看似最简单的 atomic.AddInt64(&idx, 1) % len(nodes)，实际会因节点动态剔除导致索引越界或跳过健康节点。
- 维护的是“当前可用节点切片”，不是原始注册列表；每次节点变更后重建该切片，并重置原子计数器
- 遇到调用失败（如
rpc: server error或连接超时），不能只跳过这一次——要短暂熔断该节点（例如 30 秒内不选），否则连续失败会拖垮整个请求链 - 如果节点数经常变动（比如 K8s 频繁滚动更新），建议改用
least_request或带权重的一致性哈希，比纯轮询更抗抖动
一致性哈希怎么避免“冷热不均”？加盐和虚拟节点都得有
直接对 user_id 做 sha256 取模，遇上 ID 连续或大量 0 值，流量全打到同一台机器上是常态。
立即学习“go语言免费学习笔记（深入）”；
- 必须加盐：用服务名 + 环境名（如
"user-svc-prod"）拼接后再哈希，打破输入规律 - 虚拟节点数设为物理节点数 × 128，用
github.com/serialx/hashring而不是手写环结构 - 一致性哈希只适合“请求可哈希”的场景（如读用户资料），别用在写操作或带事务的调用上——状态不一致风险太高
- 上线新节点后，观察 P95 延迟是否突增；若突增，说明哈希分布被扰动，需检查 salt 是否全局统一
真正难的从来不是实现某个算法，而是让 节点列表更新、健康探测、策略执行 和 调用反馈 四件事在毫秒级完成且互不干扰。漏掉任意一环，再漂亮的轮询代码也只会把流量稳稳导进故障节点里。
