gRPC服务发现与自定义解析实现

本文深入剖析了 gRPC 自定义服务发现（Resolver）在 Go 语言中的核心实现机制与高频踩坑点，强调必须严格实现 `resolver.Builder` 和 `resolver.Resolver` 两个接口的全部关键方法（尤其是非空 `Build()`、有实际刷新逻辑的 `ResolveNow()` 以及资源清理到位的 `Close()`），并通过 `resolver.Register` 显式注册、配合正确 scheme（如 `myresolver:///service-name`）触发调用；同时澄清 Resolver 的职责边界——它只负责动态提供带丰富元信息（如 `ServerName`、`Attributes`、`Metadata`）的地址列表，绝不应越界创建连接，真正的连接池管理、负载均衡和健康感知均由 gRPC 内部基于 `UpdateState()` 回调协同 Balancer 完成，唯有 Resolver 与 Balancer 协同传递结构化标签，才能支撑区域路由、权重调度等高级流量治理能力。

gRPC Resolver 接口必须实现哪些方法才能被识别

gRPC 的 Resolver 不是插件式注册，而是通过 resolver.Register 显式注册后，由 scheme（如 mydns://）触发调用。核心在于实现 resolver.Builder 和 resolver.Resolver 两个接口。

常见错误是只写解析逻辑但没导出 Build() 方法，或返回的 Resolver 没实现 ResolveNow() 和 Close() —— 这会导致 gRPC 启动时静默失败，日志里只报 resolver returned nil 或直接 panic。

• Build() 必须返回非 nil 的 resolver.Resolver 实例，且内部需能触发首次解析（比如启动 goroutine 调用 watch()）
• ResolveNow() 不能空实现：它用于主动刷新地址，若不做任何事，服务实例上下线就无法感知
• Close() 必须清理后台 watch goroutine 和 channel，否则连接池会持续引用已下线节点

如何让 gRPC 客户端使用自定义 Resolver 而不改 Dial 参数

关键不是改 grpc.Dial()，而是提前注册 + 统一使用对应 scheme。比如注册了 myresolver，就必须用 myresolver:///service-name 作为 target，不能混用 dns:/// 或裸 IP。

容易踩的坑是：本地开发时用 localhost:8080 测试，上线却忘了切回自定义 scheme，结果 resolver 根本没加载，客户端直连失败还查不出原因。

• 注册必须在 main() 开头或 init() 中完成：resolver.Register(&myBuilder{})
• target 字符串必须以注册的 scheme 开头，且带三个斜杠：myresolver:///user-service（注意不是两个）
• 如果要用环境变量或配置中心控制 scheme，务必确保所有服务间 scheme 一致，否则部分 client 会 fallback 到默认 resolver

动态连接池管理：为什么不能在 Resolver 里直接 new ClientConn

Resolver 只负责提供地址列表（resolver.Address），不负责建连。gRPC 内部会基于这些地址按需创建和复用 *grpc.ClientConn。如果你在 Resolver 里手动 dial，不仅绕过负载均衡策略，还会导致连接泄漏和健康检测失效。

典型症状是：服务扩缩容后，客户端仍往已下线节点发请求，错误日志出现大量 connection refused 或 transport is closing，但 Resolver.ResolveNow() 其实已经更新了地址。

• 真正该做的是在 UpdateState() 回调中，把新地址列表交给 gRPC 内部处理：cc.UpdateState(resolver.State{Addresses: addrs})
• 连接池行为由 grpc.WithTransportCredentials()、grpc.WithBlock() 等 Dial 选项控制，和 Resolver 无关
• 若需细粒度控制连接生命周期（比如按 region 分流），应在 Balancer 里实现，而不是在 Resolver 里 hold conn

Resolver 返回地址时，哪些字段影响负载均衡和重试

resolver.Address 不只是 IP+Port。gRPC 会读取其中的 ServerName、Attributes 和 Metadata 字段，决定是否启用 TLS、走哪个 Balancer、甚至是否跳过健康检查。

最常被忽略的是 Attributes：它是任意键值对，Balancer 可从中提取权重、区域标签、版本号等信息。没设这个，再复杂的路由策略也白搭。

• Address.ServerName 会被用于 TLS SNI，若为空且启用了 TLS，握手会失败
• Address.Attributes 必须用 balancer.NewPickerBuilder().Build() 可识别的结构传入，推荐用 attributes.New("region", "shanghai")
• Address.Metadata 是透传给底层 transport 的，一般不用；误塞大对象会导致内存占用异常升高

复杂点在于：Resolver 和 Balancer 必须协同工作。Resolver 提供带标签的地址，Balancer 才能做加权轮询或 locality-aware 路由——单边实现没意义。

到这里，我们也就讲完了《gRPC服务发现与自定义解析实现》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！