go负载均衡核心在于算法选择、故障防护与权重防漂移：轮询需健康检查兜底，加权轮询宜用加权随机+原子总权重，生产推荐go-zero的p2c+ewma，ai多模型场景应结合动态权重与熔断降级。
go 语言实现负载均衡算法，核心不在于“能不能写出来”，而在于“选哪个算法、怎么防故障、权重怎么更新才不漂移”。轮询看着简单，但线上一出节点宕机，next() 返回个不可用地址，整个链路就断了。
轮询（RoundRobin）必须加健康检查兜底
裸写的 RoundRobin 结构体只维护一个 index，遇到节点挂掉时会继续轮到它，导致请求失败率飙升。真实场景里必须和健康状态联动：
- 后端列表不能是静态
[]string，得是[]*Backend，每个含Alive bool字段 -
Next()不能直接取模，要跳过!b.Alive的节点，且需设最大重试次数（比如 3 次），避免死循环 - 必须配合异步健康检查 goroutine，定期发探针（HTTP GET /health 或 TCP 连接），更新
Alive状态 - 如果所有节点都不可用，
Next()应该 panic 或返回 error，而不是静默返回空字符串
加权轮询（Weighted Round Robin）别硬算 GCD
很多示例代码照搬经典算法，用 gcd 和 currentWeight 维护平滑性，但实际在动态扩缩容场景下容易失准：
- 权重变更不是原子操作：先改
weights切片，再重算gcd和maxWeight，中间窗口期会导致调度倾斜 - 更稳妥的做法是改用「加权随机」+「实时总权重缓存」：每次
Select()前用rand.Intn(totalWeight)抽样，只要totalWeight更新是原子的（比如用atomic.StoreInt64），就能避免一致性问题 - 如果坚持用 WRR，建议把
gcd换成预计算的最小公倍数（LCM），或直接放弃平滑性，改用「按权重重复填充数组」——简单粗暴，适合权重变化不频繁的场景
go-zero 的 P2C + EWMA 是生产首选
自己从零写负载均衡器，90% 的坑都在「如何定义节点负载」。用连接数或请求数做指标太滞后；用平均延迟又对瞬时抖动敏感。go-zero 的 P2C（Pick Two Choices）+ EWMA 组合解法更实用：
- 每次请求随机挑两个节点，比的是它们各自的
EWMA延迟值（α * newRTT + (1-α) * oldEWMA，α 通常取 0.2～0.5） - 选完后立即用本次 RTT 更新被选中的节点的 EWMA，未被选中的节点也按衰减因子缓慢下降，避免长期不被调用的节点 EWMA 错误偏高
- 关键点：EWMA 必须用
sync/atomic读写，否则并发更新会丢精度；且每个节点的 EWMA 要独立存储，不能共用一个变量
AI 多模型场景优先用加权随机 + 熔断降级
调用 OpenAI/Claude/千问等模型时，响应延迟、限流状态、价格差异远大于传统服务节点，此时轮询或 P2C 都不合适：
- 用
WeightedRandom，但权重不能固定：把「成功率 × (1 / P95 延迟) × (1 / 单次成本)」作为动态权重因子，每分钟重算一次 - 必须集成熔断器（如
gobreaker），某模型连续 5 次超时或 4xx/5xx 就临时踢出权重池，10 秒后半开试探 - 不要依赖单次
Generate()的 error 判断是否可用——有些模型失败后下次可能就恢复了，得看滑动窗口内的失败率
真正难的从来不是写对一个 Next() 函数，而是让权重更新、健康状态、延迟采样、熔断开关这四件事在高并发下保持逻辑自洽。任何脱离健康检查谈算法，都是纸上谈兵。
