作者张晋涛，API7.ai 云原生技术专家，Apache APISIX PMC 成员，Apache APISIX Ingress Controller 项目维护者。

原文链接

背景

微服务架构是当前最为流行的应用架构之一。

应用被拆分为多个服务组件，通过相互配合共同完成业务的具体逻辑和功能。

随着应用规模的增加和微服务拆分粒度的不同，一套系统内会包含很多个服务组件。

要让这些组件之间可以很好的协同，并且能彼此识别到，通常都需要引入服务注册和发现组件。

之前我们写了一篇文章专门来介绍微服务架构中的服务发现，

What Is Service Discovery in Microservices - API7.ai

简单来说，**通过引入了服务发现组件，微服务架构中的组件，只需要关注其他组件的名称即可，而无需关注其他组件的部署位置，或者部署 IP 等信息。

通过服务发现组件可以动态的进行获取。**

Kubernetes 中的服务发现

在 Kubernetes 环境中，Pod 是最小的调度单元。

而且在 Kubernetes 中，Pod 的 IP 不具备持久性，常常会发生变更。彼此协同的组件，一旦 IP 发生变更，很难再很好的配合工作。

所以将业务部署在 Kubernetes 环境中，如何能适配这种动态的环境就显的更加重要了。

Kubernetes 考虑到了这方面的诉求，它默认提供了基于 DNS 的服务发现机制。

Kubernetes 中有一个概念叫作 Service，它类似于反向代理的作用。客户端仅仅需要知道 Service 的存在，而无需关注它背后的 Pod 的变化，每个 Service 都会分配一个持久化的 ClusterIP 。

这样在业务组件的 Pod IP 发生变化的时候，其他组件仍然可以正常的通过 Service 的 ClusterIP 进行协同。

同时，Kubernetes 中的 Service 会自动的在集群内的 DNS 中添加一条 A 记录。

它的形式类似于：

my-svc.my-namespace.svc.cluster-domain.example

客户端可以进行相同 namespace 或者跨 namespace 的解析，这就大大的方便了需要协同工作的组件之间进行服务发现。

但是，对于传统的微服务架构，正如本文开头提到的那样，通常是利用服务注册和发现组件来实现服务间协同配合的。

想要完全适配 Kubernetes 环境中基于 DNS 的这种服务发现机制，需要一定的改造成本。

所以，如果想要较低的改造成本，那就需要继续保持原有的服务注册和发现机制。

在这个大前提下，迁移至 Kubernetes 中的服务，如何对外暴露给客户端使用呢？

APISIX Ingress 是 Kubernetes 中的一种 Ingress Controller 实现，使用 APISIX 作为数据面代理组件，

支持通过 Ingress，自定义 CRD，Gateway API 等方式进行代理规则的配置。

同时也提供了与服务注册和发现组件的集成，可以方便的与服务发现组件进行联动。

将注册在其中的服务代理出来，提供给客户端使用。

这一节将具体进行介绍。

APISIX 对服务发现的支持

APISIX 是一个高性能，全动态的云原生 API 网关，提供了 80+ 开箱即用的插件，涵盖了绝大多数用户的使用场景，其中一个很优秀的能力就是与服务发现组件的集成。

APISIX 可以和以下服务发现组件进行集成使用：

• Consul
• DNS
• Eureka
• Nacos

仅需要在 APISIX 的配置文件中添加如下配置即可（以 DNS 为例）：

discovery:
   dns:
     servers:
       - "127.0.0.1:8600"          # use the real address of your dns server

这样，在配置上游的时候，APISIX 便可通过服务发现组件动态的解析出实际的上游地址信息，并进行请求的代理。

APISIX Ingress 如何做

APISIX Ingress 使用 APISIX 作为数据面代理组件。

再进行与服务发现组件集成的时候，我们考虑了两种模式。

• 控制面集成：在 Ingress Controller 中配置服务发现组件，并进行配置的解析，将最终结果发送至 APISIX 进行代理；
• 数据面集成: 在 APISIX 数据面配置服务发现组件，代理时，由数据面进行配置解析和代理;

这两种方案各有优势，但考虑到配置的实时更新，还有方案的成熟度，我们最终选择了数据面集成的方案。

用户使用这种方案时，可以以更加低成本的方式进行接入，而且这种方案已经非常成熟了，经过了大量的生产验证。

在 APISIX Ingress 中如何使用这种方案呢？

首先确保在 APISIX 的配置中已经包含了正确的服务发现组件的配置，以下用 DNS 为例：

discovery:
  dns:
    servers:
      - "10.96.0.10:53"

创建 ApisixUpstream 资源，它的 discovery 相关的配置根据实际情况进行修改，比如此处设置了 type: dns 和具体要代理的 serviceName:

# httpbin-upstream.yaml
apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
  name: httpbin-upstream
spec:
  discovery:
    type: dns
    serviceName: httpbin.default.svc.cluster.local

最后创建一个 ApisixRoute 资源，它的 upstreams 引用刚才创建的 ApisixUpstream 资源即可：

# httpbin-route.yaml
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: httpbin-route
spec:
  http:
  - name: rule1
    match:
      hosts:
      - local.httpbin.org
      paths:
      - /*
    upstreams:
    - name: httpbin-upstream

将上述资源都正确创建后，通过 local.httpbin.org 访问，即可访问到 DNS 中已经注册了的 httpbin.default.svc.cluster.local 了。

通过这种集成，对于已经使用了服务注册发现组件的用户场景，可以非常方便的通过 APISIX Ingress 将其中的服务暴露给客户端使用。

大多数 Ingress Controller 都是没有提供这种集成方案的，这也可以增加 APISIX Ingress 的应用场景。

希望 APISIX Ingress 可以更好的满足用户实际业务场景的需求。

API7.ai 是一家提供 API 处理和分析的开源基础软件公司，于 2019 年开源了新一代云原生 API 网关 -- APISIX 并捐赠给 Apache 软件基金会。此后，API7.ai 一直积极投入支持 Apache APISIX 的开发、维护和社区运营。与千万贡献者、使用者、支持者一起做出世界级的开源项目，是 API7.ai 努力的目标。