API网关后端云原生微服务【免费下载链接】apisixThe Cloud-Native API Gateway and AI Gateway项目地址https://gitcode.com/gh_mirrors/api/apisix点击查看免费下载导读Apache APISIX 内置了基于 DNS 的服务发现能力允许直接借助 Consul 等支持 DNS 协议的服务发现系统获取上游节点列表且七层HTTP与四层Stream均适用。本文以官方文档 docs/zh/latest/discovery/dns.md 为主体结合仓库内 apisix/discovery/dns/init.lua、apisix/discovery/dns/schema.lua 等源码实现与 t/discovery/dns/sanity.t 测试用例系统讲解 DNS 服务发现的配置方式、查询顺序与 TTL 缓存机制、SRV 记录的特殊处理逻辑帮助读者在实际网关场景中正确落地该功能。一、为什么需要基于 DNS 的服务发现部分服务发现系统如 Consul除了提供 HTTP API 之外还支持通过 DNS 协议向外暴露服务信息。DNS 是历史最悠久、兼容性最广的分布式协议之一几乎所有基础设施都内置 DNS 客户端因此利用 DNS 实现服务发现可以无需额外引入 SDK 或定时轮询 HTTP 接口降低接入成本同时服务于七层HTTP/HTTPS 代理与四层TCP/UDP Stream代理场景与 APISIX 现有的域名解析能力天然衔接复用其缓存机制。在 APISIX 中DNS 服务发现与在 Upstream 的nodes中直接配置域名有着本质区别这一点在后文会详细对比。二、启用 DNS 服务发现配置 DNS 服务器在conf/config.yaml中增加discovery.dns配置段指定 DNS 服务器的地址# 添加到 config.yaml discovery: dns: servers: - 127.0.0.1:8600 # 使用 DNS 服务器的真实地址几点说明servers为数组可配置多个 DNS 服务器地址格式为host:port若只写 IP 而不带端口会默认使用 53 端口见测试用例 sanity.t 的 TEST 1配置127.0.0.1后日志显示connect to 127.0.0.1:53除了servers配置段还支持resolv_conf与order两个可选字段其合法性由 apisix/discovery/dns/schema.lua 校验。配置项 schema 约束从 schema.lua 源码可以看到完整的配置校验规则配置项类型约束说明serversarrayminItems 1元素为 stringDNS 服务器地址列表resolv_confstring无指定自定义 resolv.conf 文件路径如build-cache/test_resolve.conforderarrayminItems 1maxItems 5uniqueItems true元素枚举为last/SRV/A/AAAA/CNAME自定义 DNS 解析顺序此外 schema 规定servers与resolv_conf二者必须至少提供一个oneOf约束即要么显式指定 DNS 服务器地址要么通过系统或自定义的 resolv.conf 来获取 DNS 服务器。测试 sanity.t 的 TEST 17/18/19 验证了这些约束order中出现枚举外的值如B、小写a会报matches none of the enum values出现重复项会报expected unique items but items 1 and 2 are equal并导致配置加载失败。三、通过 Upstream 接入 DNS 服务发现启用发现能力后在 Upstream 中通过discovery_type: dns与service_name指定要解析的服务名{ id: 1, discovery_type: dns, service_name: test.consul.service, type: roundrobin }与 nodes 中配置域名的区别返回全部记录与在 Upstream 的nodes对象中直接配置域名不同DNS 服务发现会返回该域名下的所有记录。例如上述配置中test.consul.service被解析为1.1.1.1和1.1.1.2其效果等同于如下静态配置{ id: 1, type: roundrobin, nodes: [ {host: 1.1.1.1, weight: 1}, {host: 1.1.1.2, weight: 1} ] }注意普通 A/AAAA 记录解析出的所有 IP 拥有相同的权重均为 1。这正是服务发现与静态节点的差异——节点列表由 DNS 动态产出后端扩容或缩容时无需改动 APISIX 配置APISIX 会随 DNS 记录的 TTL 过期自动刷新节点列表。在 service_name 中指定端口如果希望强制使用某个端口作为上游端口可以直接把它追加到service_name字段中{ id: 1, discovery_type: dns, service_name: test.consul.service:1980, type: roundrobin }在源码 apisix/discovery/dns/init.lua 的_M.nodes()中可以看到端口解析逻辑先用core.utils.parse_addr(service_name)拆出host与port若service_name中显式携带端口则该端口优先于 DNS 记录自带的端口local node_port port if not node_port and r.port ~ 0 then -- if the port is zero, fallback to use the default node_port r.port end测试 sanity.t 的 TEST 15 SRV (override port) 专门验证了这一点即使 SRV 记录本身携带端口service_name: port.srv.test.local:1980仍会将所有节点端口覆盖为 1980。四、TTL 缓存与自定义解析顺序解析得到的记录会根据其 TTLTime To Live进行缓存。对于缓存中不存在的服务APISIX 默认按照SRV - A - AAAA - CNAME的顺序依次尝试查询而刷新缓存记录时则从上次查询成功的记录类型开始尝试避免每次刷新都从头遍历所有类型、减少无效 DNS 请求。这一默认行为对应 init.lua 中的代码local default_order {last, SRV, A, AAAA, CNAME} local order core.table.try_read_attr(local_conf, discovery, dns, order) order order or default_order其中last是一个特殊标记表示从上次成功的类型开始。通过配置文件自定义解析顺序可以根据网络环境调整解析顺序例如优先 A 记录# 添加到 config.yaml discovery: dns: servers: - 127.0.0.1:8600 # 使用 DNS 服务器的真实地址 order: # DNS 解析的顺序 - last # last 表示从上次成功的类型开始 - SRV - A - AAAA - CNAMEorder数组的顺序即查询优先级。测试 sanity.t 的 TEST 4 prefer A to AAAA 验证了同时存在 A 与 AAAA 记录时默认优先解析 AIPv4TEST 16 prefer A than SRV when A is ahead of SRV in config.yaml 则验证了将order配置为[A, SRV]后即使域名同时存在 SRV 记录也会优先按 A 记录解析到默认端口 80证明order配置确实生效。缓存相关的混合场景由 t/discovery/dns/mix.t 覆盖同一个域名既可以出现在普通 Upstream 的nodes中走全局 resolver也可以出现在 DNS 服务发现中走 discovery 专用的 DNS client两者各自独立缓存、互不干扰。五、SRV 记录指定端口与权重仅靠 A/AAAA 记录无法表达端口与权重信息。SRV 记录RFC 2782专门用于描述哪个主机在哪个端口提供哪个服务、权重与优先级如何因此当后端服务端口不统一或需要权重分配时应使用 SRV 记录。一个完整的 SRV 解析示例假设 DNS 中存在如下记录blah.service区域下; under the section of blah.service A 300 IN A 1.1.1.1 B 300 IN A 1.1.1.2 B 300 IN A 1.1.1.3 ; name TTL type priority weight port srv 86400 IN SRV 10 60 1980 A srv 86400 IN SRV 20 20 1981 BUpstream 配置如下{ id: 1, discovery_type: dns, service_name: srv.blah.service, type: roundrobin }其效果等同于以下静态 Upstream{ id: 1, type: roundrobin, nodes: [ {host: 1.1.1.1, port: 1980, weight: 60, priority: -10}, {host: 1.1.1.2, port: 1981, weight: 10, priority: -20}, {host: 1.1.1.3, port: 1981, weight: 10, priority: -20} ] }该示例揭示出 SRV 处理的三个核心规则目标主机解析为多个 IP 时权重均分目标B解析出1.1.1.2与1.1.1.3两个 IPSRV 权重 20 被平分给两者各 10优先级取负数SRV 中优先级数值越低越先被选中而 APISIX 内部节点priority字段语义相反数值越大优先级越高因此源码中做了取负转换nodes[index].priority -r.priority于是priority10变为-10priority20变为-20从而保证低优先级数值小的节点排在前面被优先选中端口来自 SRV 记录除非service_name中显式指定端口覆盖。关于 0 权重的 SRV 记录RFC 2782 中关于权重为 0 的记录是这样描述的当没有任何候选服务器时域管理员应使用权重为 0 的使 RR 更为易读噪音更少。当存在权重大于 0 的记录时权重为 0 的记录被选中的可能性很小。APISIX 的处理策略是把权重为 0 的记录当作权重为 1因此这类节点被选中的可能性很小这也正是处理此类记录时常用的做法。测试 sanity.t 的 TEST 10 SRV (zero weight) 验证了这一点——0 权重的节点最终以权重 1 出现在 upstream nodes 中。关于端口为 0 的 SRV 记录对于端口为 0 的 SRV 记录APISIX 会使用上游协议的默认端口HTTP 为 80。测试 sanity.t 的 TEST 14 SRV (port is 0) 显示端口为 0 的 SRV 记录最终请求落在proxy request to 127.0.0.1:80。同时如果你在service_name字段中直接指定端口如srv.blah.service:8848则该端口优先生效覆盖 SRV 记录中的端口。此外在四层stream子系统中源码会直接丢弃端口为 0 的节点if node_port or is_http判断避免无端口可用的无效节点进入负载均衡列表。六、源码级原理解析流程与权重算法理解底层实现有助于排查问题。DNS 服务发现的完整调用链如下加载发现模块apisix/discovery/init.lua 根据local_conf.discovery中的配置动态加载对应的apisix.discovery.name模块并在init_worker阶段调用其init_worker()初始化 DNS 客户端apisix/discovery/dns/init.lua 的init_worker()读取servers、resolv_conf与order构造core.dns_client.new({hosts {}, resolvConf resolv_conf, nameservers servers, order order})失败则直接error中止启动按需解析节点_M.nodes(service_name)被上游解析逻辑调用使用RETURN_ALL模式对应 apisix/core/dns/client.lua 中的RETURN_ALL 2获取域名的全部记录逐条转换为{host, weight, port, priority}节点。SRV 权重均分与最小公倍数修正SRV 权重均分后可能出现小数如权重 20 分给 3 个 IP而节点权重必须为整数。apisix/core/dns/client.lua 中的resolve_srv()函数处理了这一细节对每条 SRV answer先递归解析其target主机名A/AAAA 记录得到 N 个 IP将该 SRV 的权重weight / count均分给每个 IP端口与优先级从 SRV 记录继承统计所有 answer 的解析数量计算最小公倍数LCM再将每个均分权重乘以 LCM 还原为整数从而保证相对权重比例不变。测试 sanity.t 的 TEST 11 SRV (split weight) 验证了多 IP 均分场景TEST 12 SRV (priority) 则通过日志顺序proxy request to 127.0.0.1:1979先于proxy request to 127.0.0.2:1980证明了低优先级 SRV 节点优先被选中。七、实践建议结合上述配置与源码行为在实际使用中有几点值得注意配置校验先行order字段存在枚举与去重约束若配置错误会导致 APISIX 启动失败可通过apisix test或观察启动日志提前发现合理设置 TTLDNS 记录 TTL 决定节点刷新的频率TTL 过短会增加 DNS 服务器压力过长则后端故障恢复不灵敏建议根据后端变更频率权衡端口策略四层代理场景下端口为 0 的节点会被忽略务必通过 SRV 记录或service_name显式提供端口排查手段APISIX 日志中discovery dns with host ..., port ...、upstream nodes: {...}以及dns resolve ...等日志可直接观察解析结果与最终节点列表是定位问题最直接的入口。总结DNS 服务发现是 APISIX 众多服务发现方式中最轻量的一种无需额外依赖仅通过标准的 DNS 协议即可对接 Consul 等系统同时覆盖七层与四层代理。理解其返回全部记录、权重均等A/AAAA、SRV 提供端口与权重、TTL 驱动刷新、order 自定义解析顺序等核心行为结合 apisix/discovery/dns/init.lua 的实现细节与 t/discovery/dns/sanity.t、t/discovery/dns/mix.t 的测试覆盖开发者可以在生产环境中准确地配置与排障让 DNS 服务发现稳定地服务于动态扩缩容场景。赞分享API网关后端云原生微服务【免费下载链接】apisixThe Cloud-Native API Gateway and AI Gateway项目地址https://gitcode.com/gh_mirrors/api/apisix点击查看免费下载相关推荐Apache APISIX 基于 DNS 的服务发现配置、SRV 记录与源码级原理解析Apache APISIX 基于 DNS 的服务发现配置、SRV 记录与源码级原理解析 导读 本文以 Apache APISIX 官方文档 docs/en/lAPI网关后端云原生微服务Apache APISIX 基于 DNS 的服务发现配置实战与 SRV 记录原理剖析Apache APISIX 基于 DNS 的服务发现配置实战与 SRV 记录原理剖析 Apache APISIX 提供了多种服务发现Service Disc后端微服务云原生APISIX DNS 服务发现实战配置解析、SRV 记录语义与源码级原理APISIX DNS 服务发现实战配置解析、SRV 记录语义与源码级原理 APISIX 的 DNS 服务发现 discovery.dns 允许网关直接通过后端微服务云原生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考