根本原因是gRPC-Go v1.27+默认禁用客户端负载均衡，必须显式配置grpc.WithDefaultServiceConfig({"loadBalancingPolicy":"round_robin"})并配合DNS解析器及可解析为多个A记录的域名，否则仍沿用pick_first策略只连首个地址。
gRPC 客户端启用 round_robin 时为什么没生效
根本原因是 gRPC-Go v1.27+ 默认禁用客户端负载均衡，不显式配置就只打第一个地址。常见错误是只写 grpc.WithBalancerName("round_robin") 却漏掉 resolver 或 service config。
- 必须导入 DNS resolver：确保已执行
_ "google.golang.org/grpc/resolver/dns"，否则dns:///service-name解析失败 - 目标地址不能是 IP 列表或单个 host，得是可解析为多个 A 记录的域名（如 Kubernetes Headless Service 的
user-srv.default.svc.cluster.local） - 推荐用
grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy":"round_robin"}`)替代WithBalancerName，后者在新版本中已被标记为 legacy - 若用
passthrough:///10.0.1.1:8080,10.0.1.2:8080，必须同时指定 balancer，否则 panic 报错："no load balancing policy configured"
HTTP 客户端做轮询时如何避免雪崩式重试
手动实现 RoundTripper 轮询时，最常踩的坑是把故障节点立刻踢出但没退避，导致刚恢复的节点瞬间被压垮。
- 不要仅靠单次 HTTP 5xx 或
connection refused就永久剔除——应设临时退避窗口，比如sync.Map存map[string]time.Time，键为host:port，值为“下次可重试时间” - 每次
RoundTrip前先查退避状态，过期才参与轮询；未过期则跳过并 fallback 到下一个实例 -
context.DeadlineExceeded不会自动触发退避，需在 error 分支里显式判断并记录退避时间 - 连接池要复用：
http.Transport.MaxIdleConnsPerHost至少设为 100，否则高并发下新建连接耗尽 fd
自适应权重怎么从 Prometheus 拿指标实时更新
不是轮询拉指标再算权重，而是让每个后端服务主动上报健康分，客户端按分加权选节点——更准、更低延迟、不依赖中心化监控链路。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 后端服务暴露
/health/weighted接口，返回 JSON：{"score": 0.82, "reason": "cpu=65%, latency_p99=120ms"} - 客户端用 goroutine 定期（如 5s 间隔）调用所有实例该接口，结果存入
atomic.Value缓存的map[string]float64 - 加权轮询时，用 score 当前权重，而非静态配置；score 归一化后参与概率选择（如 roulette wheel selection）
- score ≤ 0.3 的实例直接从候选列表剔除，不参与任何调度，避免“带病上岗”
go-zero 的动态路由和手写 balancer 的关键区别
go-zero 不是封装了个轮询函数，它把路由决策下沉到了网关层，并与熔断器、限流器、指标采集深度耦合，所以能做真正闭环的负载感知。
立即学习“go语言免费学习笔记（深入）”；
- 它的
WeightedBalancer读取的是运行时指标（如每秒请求数、平均延迟、错误率），不是配置文件里的数字 - 路由变更通过 etcd watch 实时推送，无需 reload 进程，策略切换毫秒级生效
- 每个后端节点有独立连接池和超时控制，一个节点抖动不会污染其他节点的连接复用
- 如果你自己写 balancer，最容易忽略的是连接粒度 vs 请求粒度——gRPC 的
round_robin是连接级轮询，而 go-zero 是请求级，这对长连接场景影响极大
