Apache APISIX 是一个动静、实时、高性能的云原生 API 网关,提供了负载平衡、动静上游、灰度公布、服务熔断、身份认证、可观测性等丰盛的流量治理性能。作为云原生 API 网关,Apache APISIX 也集成了多种服务发现的能力,本文将为您展现在 Apache APISIX 中如何配置 CoreDNS。
背景信息
在传统的物理机和虚拟机部署中,各个服务之间的调用能够通过固定 IP + 端口 的形式进行。随着云原生时代的到来,企业业务的部署更偏向于云原生容器化。然而在容器化环境中,服务实例的启动和销毁是十分频繁的,如果通过运维人员手动保护不仅工作量大,而且成果也欠佳。因而须要一种机制能够自动检测服务状态,当服务地址呈现变更时,动静绑定新的地址。服务发现机制应运而生。
服务发现简介
服务发现机制能够分为两局部:
- 服务注册核心:存储服务的主机和端口信息。
如果某个容器对外提供计算平均值的服务,咱们应用 average
的服务名作为惟一标识符,那么在服务注册核心就会以键值对(average:192.168.1.21
)的形式存储。
- 服务发现:容许其余用户发现服务注册阶段存储的信息。分为客户端发现模式和服务端发现模式。
客户端服务发现模式
在应用客户端发现模式时,客户端通过查问服务注册核心的存储信息,获取可用服务的理论网络地址后,通过负载平衡算法抉择一个可用的服务实例,并将申请发送至该服务。
长处:架构简略,扩大灵便,不便实现负载平衡性能。
毛病:重客户端,强耦合,有肯定开发成本。
客户端发现模式实现逻辑如下:
- 新服务启动时,被动向注册核心注册,服务注册核心会存储新服务的服务名和地址;
- 当客户端须要这个服务时,会应用服务名向服务注册核心发动查问;
- 服务注册核心返回可用的地址,客户端再依据具体的算法抉择其中一个发动调用。
在这个过程中,除了服务注册,服务发现的工作根本由客户端独立实现,注册核心和服务端的地址对客户端也是齐全可见的。
服务端服务发现模式
客户端向 Load Balancer 发送申请,Load Balancer 依据客户端的申请查问服务注册核心,找到可用的服务后转发申请到该服务上,和客户端服务发现模式一样,服务都须要在注册核心进行服务注册和登记。
长处:服务的发现逻辑对客户端是通明的。
毛病:须要额定部署和保护负载均衡器。
服务端发现模式实现逻辑如下:
- 新服务启动时,被动向注册核心注册,服务注册核心会存储新服务的服务名和地址;
- 当客户端须要某个服务时,会应用服务名向负载均衡器发动查问;
- 负载均衡器依据客户端申请的服务名,代理客户端向服务注册核心发动申请;
- 负载均衡器取得返回的地址后,依据具体的算法抉择其中一个发动调用。
应用 CoreDNS 的劣势
CoreDNS 是一个用 Go
语言编写的开源 DNS 服务器,因为它的灵活性和可扩展性,罕用于多容器环境中的 DNS 服务和服务发现。CoreDNS 建设在 Caddy 这个 HTTP/2 Web 服务器之上,实现了一个插件链的架构,将很多 DNS 相干的逻辑都形象成了一层一层的插件,实现起来更灵便和易扩大,用户抉择的插件会被编译到最终的可执行文件中,运行效率也十分高。CoreDNS 是首批退出 CNCF(云原生计算基金会)并且是曾经毕业的云原生开源我的项目,也是 Kuberneters 中默认的 DNS 服务。
相比于常见的服务发现框架(Zookeeper 和 Consul),CoreDNS 实现服务发现有哪些劣势呢?
服务发现的原理和计算机网络中重要的基础设施—— DNS 域名零碎比拟类似,DNS 域名零碎把很少变动的域名与常常变动的服务器 IP 地址进行绑定,而服务发现机制则是把很少变动的服务名与服务地址绑定。由此咱们能够借由 DNS 实现相似服务注册核心的性能,只须要将 DNS 中存储的域名转换为服务名即可。因为许多计算机内置了 DNS 性能,所以咱们只须要在原有 DNS 零碎上批改配置就能够了,不须要做太多额定的事件。
原理架构
- 客户端向 APISIX 发动申请调用服务。
- APISIX 依据设置好的路由来拜访上游服务节点(具体配置可见下文),在 APISIX 中能够设置上游信息通过 DNS 形式获取,只有正确设置了 DNS 服务器的 IP 地址,APISIX 会主动向该地址发动申请,获取 DNS 中对应服务的地址。
- CoreDNS 依据申请的服务名返回可用的地址列表。
- APISIX 依据可用地址和配置的算法,从其中抉择一个发动调用。
整体架构如下:
如何应用
前提条件
本文操作基于以下环境进行。
- 操作系统 Centos 7.9。
- Apache APISIX 2.12.1,详情请参考:如何构建 Apache APISIX。
- CoreDNS 1.9.0,详情请参考:CoreDNS 装置指南。
- Node.js 10.15.0,详情请参考:Node.js Installation。
操作步骤
- 应用 Node.js 的
Koa
框架在3005
端口启动一个简略的测试服务。
拜访此服务会返回 Hello World
的字串,稍后咱们将通过 CoreDNS 获取这个服务的地址。
// 应用 Koa 框架搭建服务
const Koa = require('koa');
const app = new Koa();
app.use(async ctx => {ctx.body = 'Hello World';});
app.listen(3005);
- 配置 CoreDNS。
CoreDNS 默认监听 53
端口,并且会读取在雷同目录中的 Corefile
配置文件。初始条件下,同目录中并没有 Corefile
文件,因而咱们须要创立并实现配置。
Corefile
次要是通过配置插件来实现性能,因而咱们须要配置三个插件:
hosts
:能够通过此参数将服务名和 IP 地址绑定,fallthrough
示意在以后插件无奈返回失常数据时能够把申请转发给下一个插件解决(如果存在)。forward
:示意将申请代理到指定的地址,个别是权威 DNS 服务器地址。log
:不配置任何参数代表将日志信息打印到控制台界面,以便进行调试。
.:1053 { # 监听在 1053 端口
hosts {
10.10.10.10 hello
# 将服务名“coredns”和 IP 地址绑定
fallthrough
}
forward . 114.114.114.114:53
log
}
- 配置 Apache APISIX。
在 conf
`/config.yaml` 文件中增加相干配置并从新加载 Apache APISIX。
# config.yml
# ...other config
discovery:
dns:
servers:
- "127.0.0.1:1053" # 应用 DNS 服务器的实在地址, 此处为本机的 1053 端口
- 配置 Apache APISIX 中的路由信息。
接下来咱们通过申请 Admin API 配置相干路由信息
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri":"/core/*","upstream": {"service_name":"hello:3005",
# 将服务名命名为 coredns,与 CoreDNS 中 hosts 插件的配置保持一致
"type": "roundrobin",
"discovery_type": "dns" # 将服务发现类型设置为 DNS
}
}'
- 验证。
a. 在本机上验证
curl 127.0.0.1:9080/core/hello -i
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Content-Length: 11
Connection: keep-alive
Date: Wed, 16 Feb 2022 08:44:08 GMT
Server: APISIX/2.12.1
Hello World
b. 在其余主机上验证
curl 10.10.10.10:9080/core/hello -i
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Content-Length: 11
Connection: keep-alive
Date: Wed, 16 Feb 2022 08:43:32 GMT
Server: APISIX/2.12.0
Hello World
通过上述返回后果能够看到,服务是能够失常运行的。
- 模仿容器因各种起因无奈提供服务,导致 IP 地址产生变更。
咱们须要在另一台服务器上搭建雷同的服务,同样运行在 3005
端口,然而 IP 地址发生变化,返回字符串改为 Hello, Apache APISIX
。
// 应用 Koa 框架搭建服务
const Koa = require('koa');
const app = new Koa();
app.use(async ctx => {ctx.body = 'Hello, Apache APISIX';});
app.listen(3005);
批改 Corefile
配置并重启 CoreDNS,其余配置不作批改。配置示例如下:
.:1053 { # 监听在 1053 端口
hosts {
10.10.10.11 hello # 批改服务 IP 地址
# 将服务名“coredns”和 IP 地址绑定
fallthrough
}
forward . 114.114.114.114:53
log
}
DNS 存在缓存机制,当咱们用
dig
命令申请解析新的域名时,在返回的DNS record
中会看到一个数字字段,即*TTL*
字段,个别是3600
,即一个小时。在TTL
时间段内发往该域名的申请不会再向 DNS 服务器申请解析地址,而是间接在本地缓存中获取该域名对应的地址。
通过验证咱们能够发现,申请曾经从新指向新的地址。验证如下:
curl 127.0.0.1:9080/core/hello -i
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Content-Length: 11
Connection: keep-alive
Date: Wed, 16 Feb 2022 08:44:08 GMT
Server: APISIX/2.12.0
Hello, Apache APISIX
总结
本文次要介绍了服务发现的类型以及在 Apache APISIX 中如何应用 CoreDNS。您能够依据本身的业务需要和过往技术架构应用 Apache APISIX 与 CoreDNS。
Apache APISIX 我的项目目前正在开发其余插件以反对集成更多服务,如果您对此有趣味,您能够通过 GitHub Discussions 发动探讨,或通过邮件列表进行交换。