gRPC 服务发现与负载均衡进阶：从 DNS 轮询到自定义 Resolver 的实战路径

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 依然是性价比最高的方案。