服务发现

SRV 通过优先级、权重、端口和目标主机名描述服务位置。它的所有者通常组合服务标签、传输标签与域名，例如 _echo._tcp.lab.test。理解该服务的客户端可以先查 SRV，再通过 A 或 AAAA 取得目标地址，连接记录给出的端口。普通主机名查询不会自动执行这套应用相关的发现流程，服务名与查询方式必须由调用方契约明确。 优先级选择可达的组，权重只在同组内起作用。文章每组只有一个目标；故障转移展示客户端处理，不是同组加权选择或 DNS 健康摘除。 坏掉的样子 发布 SRV 不会让所有现有客户端自动采用它。应用需要规定服务标签，并实际支持相应发现行为。只接受普通主机名和配置端口的浏览器或库，可能根本不询问 SRV。因此，手工查询 SRV 成功，不能证明应用已经改变端点选择，也不能据此宣布今后不再需要更新配置。验证应沿真实调用方进行，不能止于区域里已有记录。 优先级和权重不是可互换字段。在可达目标中，较低数值优先级更优先；权重只影响相同优先级记录之间的选择。较高数值备机即使具有很大权重，也不能越过可用的低数值目标。把所有记录按权重统一排序，或直接采用报文中的首项，都可能反转服务所有者设计的主备关系。解释结果前，应确认客户端是否正确使用这些字段。 发现也不证明健康。监听停止后，目标仍可继续被发布，SRV 与目标地址记录集还具有各自缓存寿命。客户端需要连接截止时间与适当重试策略。连接被拒绝后重试读取，与重复可能已产生副作用的操作不同；端点故障转移必须符合应用协议，不能因为还有候选项，就无条件把每个业务动作再执行一遍。 快速验证 将脚本保存为 check-srv-discovery.py，准备 Docker 后执行 python3 check-srv-discovery.py。固定 BIND 9.18.49 环境发布测试 _echo._tcp 服务，两个真实 HTTP 监听在不同临时端口提供可识别的只读响应。HTTP 只是实验中便于观察的载荷；示例是自定义 SRV 客户端，不代表通用 HTTP 客户端本来就实现了这个服务标签： ...