Apache APISIX 携手 CoreDNS 打开服务发现新大门

Apache APISIX 是一个动态、实时、高性能的云原生 API 网关，提供了负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。作为云原生 API 网关，Apache APISIX 也集成了多种服务发现的能力，本文将为您展示在 Apache APISIX 中如何配置 CoreDNS。

背景信息

在传统的物理机和虚拟机部署中，各个服务之间的调用可以通过固定 IP + 端口的方式进行。随着云原生时代的到来，企业业务的部署更倾向于云原生容器化。但是在容器化环境中，服务实例的启动和销毁是非常频繁的，如果通过运维人员手动维护不仅工作量大，而且效果也欠佳。因此需要一种机制可以自动检测服务状态，当服务地址出现变更时，动态绑定新的地址。服务发现机制应运而生。

服务发现简介

服务发现机制可以分为两部分：

• 服务注册中心： 存储服务的主机和端口信息。

假如某个容器对外提供计算平均值的服务，我们使用 average 的服务名作为唯一标识符，那么在服务注册中心就会以键值对（average:192.168.1.21）的方式存储。

• 服务发现：允许其他用户发现服务注册阶段存储的信息。分为客户端发现模式和服务端发现模式。

客户端服务发现模式

在使用客户端发现模式时，客户端通过查询服务注册中心的存储信息，获取可用服务的实际网络地址后，通过负载均衡算法选择一个可用的服务实例，并将请求发送至该服务。

优点：架构简单，扩展灵活，方便实现负载均衡功能。

缺点：重客户端，强耦合，有一定开发成本。

客户端发现模式实现逻辑如下：

1. 新服务启动时，主动向注册中心注册，服务注册中心会存储新服务的服务名和地址；
2. 当客户端需要这个服务时，会使用服务名向服务注册中心发起查询；
3. 服务注册中心返回可用的地址，客户端再根据具体的算法选择其中一个发起调用。

在这个过程中，除了服务注册，服务发现的工作基本由客户端独立完成，注册中心和服务端的地址对客户端也是完全可见的。

服务端服务发现模式

客户端向 Load Balancer 发送请求，Load Balancer 根据客户端的请求查询服务注册中心，找到可用的服务后转发请求到该服务上，和客户端服务发现模式一样，服务都需要在注册中心进行服务注册和注销。

优点：服务的发现逻辑对客户端是透明的。

缺点：需要额外部署和维护负载均衡器。