gRPC 服务发现与负载均衡进阶：从 DNS 轮询到自定义 Resolver 的实战路径
一、微服务扩容后的寻址困境：gRPC 连接管理的真实痛点
在 Go 微服务架构中，gRPC 凭借 Protobuf 序列化和 HTTP/2 多路复用，已经成为服务间通信的首选协议。但当服务实例从 5 个扩展到 50 个时，一个被很多人忽视的问题浮出水面：客户端到底该连谁？
默认情况下，gRPC 使用 DNS 作为服务发现机制。DNS 轮询（Round-Robin DNS）在实例少、变更频率低时勉强可用，但在实际生产中暴露出三个核心缺陷：第一，DNS 缓存 TTL 导致新实例上线后客户端无法及时感知，流量分配滞后；第二，DNS 返回的 IP 列表不携带实例健康状态，客户端可能将请求打到已宕机的节点；第三，gRPC 默认的 pick_first 策略只建立一条连接，即使 DNS 返回多个地址也只用第一个，完全丧失了负载均衡能力。
更麻烦的是，当服务注册中心从 Consul 迁移到 Nacos，或者同时存在 Kubernetes Service 和外部 VM 部署的混合场景时，DNS 方案根本无法统一管理。我们需要一套可插拔的服务发现机制，让 gRPC 客户端能实时感知实例变化，并按策略分发流量。
二、gRPC Resolver 与 LB 策略的底层协作机制
gRPC 的服务发现和负载均衡并非黑盒，其内部通过 Resolver、Balancer 和 SubConn 三个核心组件协作完成。理解这个机制，是做任何定制化的前提。
flowchart TD
A[gRPC Client Dial] --> B[Resolver]
B -->|解析目标地址| C[命名解析]
C -->|返回地址列表+属性| D[Balancer]
D -->|创建 SubConn| E[SubConn 1]
D -->|创建 SubConn| F[SubConn 2]
D -->|创建 SubConn| G[SubConn 3]
E --> H[后端实例 A]
F --> I[后端实例 B]
G --> J[后端实例 C]
D -->|Pick 策略选择| K[RPC 请求分发]
subgraph 服务发现层
B
C
end
subgraph 负载均衡层
D
E
F
G
end
Resolver 负责将 gRPC 目标地址（如 consul://user-service）解析为一组后端地址。它通过 resolver.ClientConn.UpdateState() 方法将地址列表推送给 Balancer。Resolver 本身是一个长运行的协程，需要监听注册中心的变化事件并实时推送更新。
Balancer 接收 Resolver 推送的地址列表，为每个地址创建一个 SubConn（底层传输连接），并根据选定的策略决定每次 RPC 调用使用哪个 SubConn。gRPC 内置了 pick_first（默认，只用第一个）和 round_robin（轮询）两种策略，也支持自定义 Balancer。
SubConn 是 gRPC 对底层 HTTP/2 连接的封装，每个 SubConn 对应一个后端实例。Balancer 通过 SubConn.Connect() 和 SubConn.Shutdown() 管理连接生命周期。
关键点在于：Resolver 和 Balancer 之间通过回调驱动，而非轮询。Resolver 检测到地址变化后主动推送，Balancer 收到更新后调整 SubConn 集合，整个过程无需客户端干预。
三、生产级代码实现：自定义 Consul Resolver 与加权轮询
3.1 自定义 Consul Resolver
// consul_resolver.go
// 基于 Consul 的 gRPC 服务发现 Resolver
package discovery
import (
"context"
"fmt"
"sync"
"time"
"github.com/hashicorp/consul/api"
"google.golang.org/grpc/resolver"
)
const scheme = "consul"
// ConsulBuilder 实现 resolver.Builder 接口
type ConsulBuilder struct {
client *api.Client
}
func NewConsulBuilder(consulAddr string) (*ConsulBuilder, error) {
cfg := api.DefaultConfig()
cfg.Address = consulAddr
client, err := api.NewClient(cfg)
if err != nil {
return nil, fmt.Errorf("创建 Consul 客户端失败: %w", err)
}
return &ConsulBuilder{client: client}, nil
}
func (b *ConsulBuilder) Build(
target resolver.Target,
cc resolver.ClientConn,
opts resolver.BuildOptions,
) (resolver.Resolver, error) {
r := &consulResolver{
client: b.client,
target: target.Endpoint(),
cc: cc,
quit: make(chan struct{}),
}
// 启动后台监听协程，避免阻塞 Resolver 构建过程
go r.watcher()
return r, nil
}
func (b *ConsulBuilder) Scheme() string { return scheme }
type consulResolver struct {
client *api.Client
target string
cc resolver.ClientConn
quit chan struct{}
mu sync.Mutex
}
func (r *consulResolver) watcher() {
// 首次立即解析，避免启动阶段空地址
r.resolve()
ticker := time.NewTicker(5 * time.Second)
defer ticker.Stop()
for {
select {
case <-ticker.C:
r.resolve()
case <-r.quit:
return
}
}
}
func (r *consulResolver) resolve() {
// 只查询健康检查通过的服务实例
services, _, err := r.client.Health().Service(
r.target, "", true, nil,
)
if err != nil {
r.cc.ReportError(fmt.Errorf("Consul 查询失败: %w", err))
return
}
var addrs []resolver.Address
for _, svc := range services {
addr := fmt.Sprintf("%s:%d", svc.Service.Address, svc.Service.Port)
// 将权重写入 Address 属性，供 Balancer 读取
addrs = append(addrs, resolver.Address{
Addr: addr,
ServerName: svc.Service.ID,
Attributes: newAttributesWithWeight(svc.Service.Weights.Passing),
})
}
if len(addrs) == 0 {
// 空地址列表不能直接推送，否则会断开所有连接
r.cc.ReportError(fmt.Errorf("服务 %s 无可用实例", r.target))
return
}
// 推送地址更新给 Balancer
r.cc.UpdateState(resolver.State{Addresses: addrs})
}
func (r *consulResolver) ResolveNow(resolver.ResolveNowOptions) {
// 收到 ResolveNow 信号时立即重新解析
r.resolve()
}
func (r *consulResolver) Close() {
close(r.quit)
}
3.2 注册 Resolver 并使用
// main.go
// 注册自定义 Resolver 并创建 gRPC 连接
func main() {
// 注册 Consul Resolver，必须在 Dial 之前完成
builder, err := NewConsulBuilder("consul.internal:8500")
if err != nil {
log.Fatalf("初始化 Consul Resolver 失败: %v", err)
}
resolver.Register(builder)
// 使用 consul://scheme/服务名 格式拨号
// 指定 round_robin 策略替代默认的 pick_first
conn, err := grpc.Dial(
"consul://user-service",
grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy":"round_robin"}`),
grpc.WithTransportCredentials(insecure.NewCredentials()),
)
if err != nil {
log.Fatalf("gRPC 拨号失败: %v", err)
}
defer conn.Close()
}
3.3 带健康检查的连接管理
// health_checker.go
// 定期检查 SubConn 可用性，剔除不健康实例
type HealthChecker struct {
mu sync.RWMutex
unhealthy map[string]time.Time // 记录不健康实例的标记时间
threshold time.Duration // 不健康持续时间阈值
}
func NewHealthChecker(threshold time.Duration) *HealthChecker {
return &HealthChecker{
unhealthy: make(map[string]time.Time),
threshold: threshold,
}
}
// MarkUnhealthy 标记实例为不健康
func (h *HealthChecker) MarkUnhealthy(addr string) {
h.mu.Lock()
defer h.mu.Unlock()
// 只在首次标记时记录时间，避免反复刷新
if _, exists := h.unhealthy[addr]; !exists {
h.unhealthy[addr] = time.Now()
}
}
// IsHealthy 判断实例是否仍可使用
func (h *HealthChecker) IsHealthy(addr string) bool {
h.mu.RLock()
defer h.mu.RUnlock()
markedAt, exists := h.unhealthy[addr]
if !exists {
return true
}
// 超过阈值后自动恢复，避免永久剔除
return time.Since(markedAt) > h.threshold
}
四、架构权衡与适用边界
轮询间隔与注册中心压力的矛盾。Resolver 通过定时轮询 Consul 获取服务列表，间隔越短感知越快，但注册中心的 QPS 压力也越大。当客户端数量达到数百时，5 秒轮询间隔对 Consul 的查询量可能达到每秒上百次。解决方案是引入 Watch 机制（Consul 的 Blocking Query），让服务端在数据变更时才返回，将查询模式从轮询转为长连接推送。
连接抖动与优雅摘除。当实例下线时，Resolver 推送新的地址列表，Balancer 会立即关闭对应 SubConn。如果该 SubConn 上还有未完成的 RPC，客户端会收到 UNAVAILABLE 错误。生产环境中，应该配合服务端的优雅关停（Graceful Stop）：先从注册中心摘除，等待在途请求完成后再关闭连接。
全局负载均衡的局限。gRPC 的 Balancer 是进程内的，每个客户端独立做决策，无法实现全局维度的流量调度。如果需要按机房亲和性、请求耗时等维度做全局调度，需要在服务端前置一层服务网格（如 Istio），由 Sidecar 代理统一管理。
适用边界：自定义 Resolver 方案适用于服务实例超过 10 个、变更频率高于每分钟 1 次的微服务集群。对于实例数少于 5 个的简单服务，DNS 加 round_robin 策略已经够用，引入 Consul Resolver 属于过度设计。
五、总结
gRPC 服务发现从 DNS 走向自定义 Resolver，是微服务规模化的必然选择。核心机制围绕 Resolver、Balancer、SubConn 三层展开：Resolver 负责实时解析地址并推送更新，Balancer 根据策略选择 SubConn 分发请求，SubConn 管理底层连接生命周期。在工程落地时，需要重点处理三个问题：轮询间隔与注册中心压力的平衡（优先使用 Watch 机制）、实例下线时的优雅摘除（先摘注册再关连接）、以及进程内负载均衡的全局局限（复杂场景需引入服务网格）。对于小规模服务，DNS 加 round_robin 依然是性价比最高的方案。
扫一扫
611
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
