17370845950

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 值，流量全打到同一台机器上是常态。

• 必须加盐：用服务名 + 环境名（如 "user-svc-prod"）拼接后再哈希，打破输入规律
• 虚拟节点数设为物理节点数 × 128，用 github.com/serialx/hashring 而不是手写环结构
• 一致性哈希只适合“请求可哈希”的场景（如读用户资料），别用在写操作或带事务的调用上——状态不一致风险太高
• 上线新节点后，观察 P95 延迟是否突增；若突增，说明哈希分布被扰动，需检查 salt 是否全局统一

真正难的从来不是实现某个算法，而是让 节点列表更新、健康探测、策略执行 和 调用反馈 四件事在毫秒级完成且互不干扰。漏掉任意一环，再漂亮的轮询代码也只会把流量稳稳导进故障节点里。