gRPC Go 客户端默认不启用负载均衡，需显式配置 resolver 和 balancer；推荐用 grpc.WithDefaultServiceConfig 启用 round_robin，目标地址须解析出多个 IP（如 "dns:///service.com"），键名为 "loadBalancingConfig" 且值为数组；DNS 失效常见于系统缓存、glibc 限制或未启 SRV；动态服务发现需自定义 resolver（如 etcd/consul）；健康检查必须独立实现，不可仅依赖连接建立。
gRPC Go 客户端默认不启用负载均衡，必须显式配置解析器（resolver）和均衡策略（balancer），否则即使后端有多个实例，grpc.Dial 也只会连第一个地址或退化为单点连接。
用 grpc.WithDefaultServiceConfig 启用 round_robin
这是最轻量、最推荐的起步方式，适用于 DNS 或自定义 resolver 已返回多个地址的场景：
- 必须确保目标地址（target）能被解析出多个 IP:Port，例如
"dns:///user-service.example.com"或"etcd:///user-service"；纯 IP 地址如"10.0.1.5:50051"不会触发 LB - 配置字符串中键名是
"loadBalancingConfig"（注意不是旧版的"loadBalancingPolicy"），且值为数组形式 -
grpc.WithBalancerName("round_robin")在 v1.60+ 已被标记为 deprecated，应避免使用
conn, err := grpc.Dial(
"dns:///user-service.example.com",
grpc.WithTransportCredentials(insecure.NewCredentials()),
grpc.WithDefaultServiceConfig(`{"loadBalancingConfig": [{"round_robin": {}}]}`),
)
为什么 DNS 解析可能失效？查这三点
DNS 轮询在 gRPC 中看似简单，但实际常因环境配置失败，导致始终只打到一个后端：
- 系统 DNS 缓存过长（如
systemd-resolved默认缓存 30s），客户端得不到新地址；可临时加GRPC_GO_REQUIRE_HANDSHAKE=0环境变量绕过握手校验（仅调试用） - glibc 的
getaddrinfo默认只返回首个 A 记录（尤其在 musl libc 的 Alpine 镜像中），需改用netgo构建或启用GOEXPERIMENT=netgo - 未开启 DNS SRV 记录支持：若想按权重分流，需配置 SRV 记录（
_grpc._tcp.user-service），并确保 gRPC 版本 ≥ v1.47
对接 etcd/Consul 必须实现自定义 resolver
内置 DNS resolver 无法监听服务上下线，动态扩缩容时请求仍会发向已下线节点。真实项目必须用注册中心 + 自定义 resolver：
立即学习“go语言免费学习笔记（深入）”；
- resolver.Builder 要实现
Build()和ResolveNow()，核心是监听/services/user-service/前缀下的 key 变更，并调用cc.UpdateState()推送新地址列表 - 不要手动维护
*grpc.ClientConn切片轮询——gRPC 会在 SubConn 级别自动复用连接、重连、剔除故障节点 - 开源库如
etcdv3/resolver或consul-resolver可直接集成，但注意其是否兼容你用的 gRPC 版本（v1.60+ 对 balancer 接口有 breaking change）
import "github.com/you/etcd-resolver"
etcdv3.Register() // 注册 etcd:// scheme
conn, _ := grpc.Dial("etcd:///user-service", ...)
健康检查不是 LB 的附属功能，而是前提条件
gRPC 的 round_robin 不感知后端是否真能处理请求。若某节点 CPU 拉满或卡住 Accept，它仍会被轮到：
- 服务端必须暴露
/health或 gRPC Health Checking 协议（grpc.health.v1.Health） - 客户端 resolver 应定期探测每个节点，连续失败 N 次后调用
cc.UpdateState()移除该地址；恢复时再加回 - 不要依赖 TCP connect 成功就认为服务健康——HTTP/2 连接建立成功 ≠ RPC 方法可响应；至少要发一次
Check()RPC 并设短超时（≤ 1s）
最容易被忽略的是：resolver 返回的地址列表一旦为空，gRPC 会静默降级为 pick_first 行为，而不是报错。上线前务必用 conn.GetState() 和日志确认 CONNECTING / READY 状态是否覆盖全部预期节点。
