gRPC地址解析原理及自定义DNS实现

本文深入剖析了 Go 语言中 gRPC 客户端自定义 DNS 解析器的核心原理与实战要点，揭示了为何简单替换系统 DNS 或硬编码 IP 会导致证书校验失败、负载均衡失效等严重问题；强调必须正确实现 resolver.Builder 接口，通过 goroutine 持续轮询 DNS 并动态上报地址变更，同时不可遗漏 ServiceConfig 的构造与注入——否则即使 DNS 返回多个 IP，gRPC 也会退化为单点连接；还点破了 Go 1.18+ 中 net.Resolver 的 Timeout 陷阱，指出 PreferGo=true 才是超时可控的关键，并提醒开发者务必在真实边界场景（如 DNS 空响应、高频变更、防火墙干扰）下充分验证，避免上线后因解析异常引发雪崩式故障。

gRPC客户端如何指定自定义DNS解析器

Go 的 grpc.Dial 默认走系统 DNS（net.DefaultResolver），不支持直接传入自定义解析器。想换解析逻辑，得绕过默认行为，用 resolver.Builder 注册新方案。

常见错误是试图在 grpc.Dial 的 WithAuthority 或 URL 里硬塞 IP，结果服务端证书校验失败或负载均衡失效——因为跳过了 resolver，gRPC 就不知道后端地址列表，也拿不到 ServiceConfig。

• 必须实现 resolver.Builder 接口，重点是 Build() 方法返回一个能持续更新 AddressList 的 resolver.Resolver
• 注册时用 resolver.Register(&myBuilder{})，之后在目标 URI 中写 myresolver:///service-name（注意协议名不能含下划线）
• URI 中的 service-name 会传给 Build() 的 target.Target，是你做服务发现的关键输入

resolver.Build() 里怎么把域名转成真实 IP 列表

别在 Build() 里直接调 net.LookupHost 然后一次性返回——这会导致 gRPC 不感知后续 DNS 变更，连接永远卡在初始地址上。

正确做法是启动一个 goroutine 定期轮询 DNS，并通过 watcher.Next() 向 gRPC 上报地址变更。否则服务扩缩容、VIP 切换、故障转移全失效。

• 用 net.DefaultResolver.LookupHost 或 net.Resolver 自定义超时/服务器，避免阻塞整个 resolver
• 每次查到新结果，调 watcher.UpdateState(resolver.State{Addresses: addrs})，addrs 是 []resolver.Address，IP + 端口必须带 Addr 字段
• 若 DNS 查不到，别 panic，发空列表或沿用旧地址；gRPC 会重试，但连续发错格式（比如 Addr 为空）会导致 rpc error: code = Unavailable

为什么自定义 resolver 后 Load Balancing 不生效

根本原因是没填 resolver.State.ServiceConfig。gRPC 的轮询（round_robin）、加权等策略，全靠这个 JSON 字符串驱动。空着就退化成只连第一个地址。

典型现象：日志里看到 parsed service config not provided，或者所有请求都打到同一个后端实例上，不管你怎么改 DNS 返回多少条 A 记录。

• 构造 ServiceConfig 字符串时，必须包含 "loadBalancingConfig" 字段，例如：{"loadBalancingConfig": [{"round_robin": {}}]}
• 填进 resolver.State 前，用 grpc.ParseServiceConfig 验证格式，非法 JSON 会被静默忽略
• 如果服务端用了 grpclb 协议，还要额外实现 grpclb 的 resolver，和普通 DNS resolver 是两套机制，不能混用

Go 1.18+ 中 net.Resolver 的 Timeout 设置陷阱

直接 new 一个 net.Resolver 并设 Timeout，看起来很干净，但容易漏掉 PreferGo 和 StrictErrors 的影响——尤其在容器环境里，PreferGo=false（默认）会调 getaddrinfo，而 C 库的超时不受 Go 控制，可能卡住 30 秒。

现象是 Dial 卡住、context 超时不触发、CPU 空转，debug 时发现 goroutine 堵在 runtime.cgocall。

• 强制设 PreferGo: true，这样所有 DNS 查询走 Go 原生实现，Timeout 才真正生效
• StrictErrors: true 可让解析失败立刻报错，而不是返回空列表再重试，适合调试阶段
• 别复用同一个 net.Resolver 实例跨多个 resolver 实例——它内部有缓存，不同服务共用可能导致地址污染

最麻烦的不是写不对，是写对了但没测 DNS 失效、TTL 过期、中间防火墙截断这些边界情况。上线前至少模拟一次 DNS 返回空、返回单 IP、返回 10 个 IP 且每 30 秒变一次的场景。

理论要掌握，实操不能落！以上关于《gRPC地址解析原理及自定义DNS实现》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！