Go微服务负载均衡本质是服务发现+客户端选节点，依赖注册中心或gRPC resolver；go-micro/v2通过注册→selector选节点→策略执行三步实现，默认轮询；gRPC round_robin需dns:///格式及Headless Service支持；http.RoundTripper轮询须注意原子操作、DNS缓存与健康检查；go-kit/sd+lb因组件化设计与事件驱动更可靠。
Go 语言本身不提供微服务级负载均衡能力，所有“框架内置的 LB”本质都是对服务发现 + 客户端选节点逻辑的封装，真正起作用的是你用的注册中心、gRPC resolver 或自定义 RoundTripper —— 框架只是帮你把这几块粘起来。
go-micro/v2 的负载均衡怎么工作
它不是魔法，而是三步链式调用：服务启动时向 Consul 注册地址 → 客户端调用 service.Client().Call() 时触发 selector 包 → selector 从 registry 拉取健康实例列表，再按策略（默认轮询）选一个。
-
go-micro/v2的selector默认用RoundRobin，但你可以显式换策略，比如selector.WithStrategy(selector.Random) - 服务名必须全小写，Consul 对大小写敏感，
UserSrv和usersrv被视为两个服务 -
registry接口不兼容 Etcd v3 的 gRPC API；要用 Etcd，得自己实现registry.Registrar和registry.Discoverer - 健康检查靠 Consul 自身的 HTTP/TCP 检查，
go-micro不额外做探测，挂掉的节点等 Consul 标记为critical后自动剔除
gRPC-go 的 round_robin 策略为什么总不生效
常见原因是目标地址写错了：round_robin 是连接粒度的，且只对能解析出多个 IP 的地址生效。单个 IP 或域名未配置 DNS 扩展，它就退化成 pick_first。
- 必须用
dns:///user-service这种格式，不能是user-service:8080或http://user-service - Kubernetes 中需搭配 Headless Service（
clusterIP: None），让 DNS 返回全部 Pod A 记录；否则dns:///解出来只有一个 IP - 如果不用 DNS，可用
resolver.NewAddress([]resolver.Address{...})手动注入地址，但健康状态要自己维护，round_robin不会自动剔除失败节点 - gRPC v1.60+ 默认启用
round_robin，但老版本（如 v1.47）需显式传grpc.WithBalancerName("round_robin")
用 http.RoundTripper 实现轮询时容易漏掉什么
直接改 req.URL.Host 看似简单，但忽略 Transport 层复用和 DNS 缓存，会导致扩缩容不感知、连接泄漏、甚至请求打到已下线节点。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
atomic操作维护索引，否则高并发下index++会丢计数或越界 -
http.Transport默认缓存 DNS 解析结果（TTL 由系统 DNS 决定），若后端用域名，扩容后新 Pod 的 IP 可能几小时都不生效；建议用 IP 直连，或重写transport.DialContext配合自定义 DNS 解析器 - 没做健康检查时，挂掉的节点仍会被轮到；可加简单标记：失败后
sync.Map.Store(addr, time.Now())，选节点前过滤掉 30 秒内失败过的 - 别在
RoundTrip里新建http.Client或http.Transport，复用全局实例，否则连接池失效，文件描述符暴涨
go-kit/sd + lb 为什么比手写轮询更可靠
它把“发现→缓存→选节点→失败 fallback”拆成可替换组件，每个环节都处理了生产环境的真实痛点，而不是只解决“怎么跳下一个”。
-
sd.Instancer支持 Consul/Etcd/静态配置，且自带监听机制（如 Consul watch），实例上下线实时同步，不用自己写 ticker 拉取 -
lb.Balancer封装策略，lb.NewOpportunist在首次失败后自动重试下一个节点，不是每次请求都换——避免把压力甩给所有节点 - 整个链路天然支持 context 传递，超时、取消、traceID 都能透传到底层 transport
- 实例列表更新时，
Instancer会发事件，Balancer自动 reload，无需手动重置计数器或清空缓存
最常被忽略的是健康检查与连接复用的耦合：选节点只是第一步，后续请求是否复用连接、失败后是否标记该节点为临时不可用、重试时要不要换策略——这些细节决定 LB 是“能跑”还是“能扛住线上流量”。
