登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  Golang >  Go教程

Go net.Resolver.LookupSRV 怎么把服务记录转换成可拨号地址

来源:17golang原创

时间:2026-11-05 07:00:27 201浏览 收藏

服务发现返回的不是一个现成的 host:port 字符串,而是多条 SRV 记录。Go 的 net.Resolver.LookupSRV 会按 RFC 2782 规则查询 _service._proto.name,返回已经按 Priority 排序、同优先级内按 Weight 随机化的记录。真正交给 DialContext 前,重点是用 Target 和 Port 重新组合地址,并把查询超时、空结果和拨号错误分开处理。

要点速览
  • service、proto、name 决定 SRV 查询名,通常对应 _grpc._tcp.example.com。
  • Target 是主机名,Port 是端口;组合地址应使用 net.JoinHostPort,不要手写冒号拼接。
  • Priority 表示优先级,Weight 只用于同一优先级内的选择,不能把一次返回顺序当成永久路由表。

LookupSRV 返回的四个字段分别解决什么问题

LookupSRV(ctx, service, proto, name) 的 proto 只能使用 tcp 或 udp。例如服务名是 grpc、协议是 tcp、域名是 example.com 时,查询目标通常是 _grpc._tcp.example.com。返回值还包含一个 cname,它是第一条 SRV 应答的 owner name,可能因为 CNAME 跳转而和构造出来的名字不同。

字段用途落到拨号逻辑
Target服务实例主机名作为 JoinHostPort 的 host
Port服务实例端口转成字符串后作为 port
Priority数值越小越优先先筛选最低优先级组
Weight同优先级内的相对权重再做加权选择或顺序尝试
Go net.Resolver.LookupSRV 返回 Target、Port、Priority、Weight 并转换到可拨号地址的静态结构图
图1:说明图,查看 SRV 记录字段到可拨号地址的静态关系;它不是 DNS 查询截图或运行证据。

用 JoinHostPort 把 Target 和 Port 转成拨号地址

SRV 的 Target 通常以 DNS 完全限定名形式返回,末尾可能带一个点。这个点是 DNS 名称表示的一部分,交给拨号器通常不会造成问题;如果业务日志需要统一显示,可以在展示层去掉,而不要在解析阶段随意改写主机名。地址拼接使用 net.JoinHostPort,这样即使后续得到 IPv6 字面量,也不会产生缺失方括号的问题。

package main

import (
	"context"
	"fmt"
	"net"
	"strconv"
	"time"
)

func lookupTargets(parent context.Context, service, proto, domain string) ([]string, error) {
	ctx, cancel := context.WithTimeout(parent, 2*time.Second)
	defer cancel() // 查询结束后释放计时器,避免短请求留下定时器。

	resolver := net.Resolver{}
	_, records, err := resolver.LookupSRV(ctx, service, proto, domain)
	if err != nil {
		return nil, fmt.Errorf("lookup SRV: %w", err) // 区分 DNS 失败与后续拨号失败。
	}
	if len(records) == 0 {
		return nil, fmt.Errorf("no SRV records for %s/%s/%s", service, proto, domain)
	}

	addrs := make([]string, 0, len(records))
	for _, record := range records {
		// JoinHostPort 负责端口格式化,也能正确处理 IPv6 主机。
		addrs = append(addrs, net.JoinHostPort(record.Target, strconv.Itoa(int(record.Port))))
	}
	return addrs, nil
}

func main() {
	// 示例只展示地址转换;真实程序可将 addrs 交给 DialContext 逐个尝试。
	addrs, err := lookupTargets(context.Background(), "grpc", "tcp", "example.com")
	if err != nil {
		fmt.Println(err)
		return
	}
	fmt.Println(addrs)
}

这里没有把 Priority 和 Weight 丢掉,只是先聚焦标题中的“转换成地址”。生产代码应保留记录对象,再选择最低 Priority 的集合;如果多个记录优先级相同,再按 Weight 做加权抽样或故障转移。Go 文档说明返回结果已经完成优先级排序并在同优先级内按权重随机化,因此调用方不必再次把所有记录当作无序列表排序。

查询成功不等于下一次拨号一定成功

SRV 只告诉你服务记录存在。Target 还可能需要 A/AAAA 解析,网络策略也可能拒绝该端口,所以应把流程拆成“查询—地址构造—连接”三个错误边界。查询超时返回 context.DeadlineExceeded 时,适合记录为发现阶段失败;地址列表为空时不要调用 DialContext;连接失败则可以在同一优先级的其他候选上继续尝试,但不要跨越更高优先级组。

Go LookupSRV 的 Priority 优先级、Weight 同级选择和 DialContext 连接边界静态结构图
图2:结构图,展示 Priority、Weight 与 DNS 查询、地址构造、拨号错误之间的边界;它不是实际运行结果。

还有一个容易误判的场景:如果 service 和 proto 都是空字符串,LookupSRV 会直接查询 name,适合少数非标准发布方式。不要在普通调用中把下划线服务名手工塞进 name 后又传入非空的 service/proto,否则会得到重复的查询层级。

把 SRV 记录接入拨号器的检查清单

接入前可以按四项核对:① 查询使用带截止时间的 context;② 记录的 Target 与 Port 通过 JoinHostPort 组合;③ 只在最低 Priority 组内依据 Weight 选择;④ 日志同时保留查询名、cname、候选地址和最终错误。这样当服务不可用时,能判断是 DNS 没返回记录、目标主机解析失败,还是端口连接被拒绝,而不是只得到一句“连接失败”。

相关问题

LookupSRV 返回的 Target 能直接传给 Dial 吗?

不能直接传。它是主机名,不含端口;应将 Target 和 Port 通过 net.JoinHostPort 组合成地址。

Weight 越大是不是一定先连接?

不是。Weight 是同一 Priority 组内的相对选择权重,结果仍受抽样、重试和连接失败影响,不能当成严格顺序。

为什么不手写 target + ":" + port?

因为 IPv6 地址需要方括号,而且端口格式化也应集中处理。JoinHostPort 能避免这两类边界错误。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>