Golang gRPC如何支持负载均衡_Golang gRPC LB配置方式

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 状态是否覆盖全部预期节点。