云原生场景下是否需要服务发现
背景
微服务架构是当前最为流行的应用架构之一。 应用被拆分为多个服务组件，通过相互配合共同完成业务的具体逻辑和功能。
随着应用规模的增加和微服务拆分粒度的不同，一套系统内会包含很多个服务组件。 要让这些组件之间可以很好的协同，并且能彼此识别到，通常都需要引入服务注册和发现组件。
之前我们写了一篇文章专门来介绍微服务架构中的服务发现， 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 记录。
它的形式类似于：
1my-svc.my-namespace.svc.cluster-domain.example客户端可以进行相同 namespace 或者跨 namespace 的解析，这就大大的方便了需要协同工作的组件之间进行服务发现。
但是，对于传统的微服务架构，正如本文开头提到的那样，通常是利用服务注册和发现组件来实现服务间协同配合的。 想要完全适配 Kubernetes 环境中基于 DNS 的这种服务发现机制，需要一定的改造成本。
所以，如果想要较低的改造成本，那就需要继续保持原有的服务注册和发现机制。 在这个大前提下，迁移至 Kubernetes 中的服务，如何对外暴露给客户端使用呢？
APISIX Ingress 如何与注册中心联动
APISIX Ingress 是 Kubernetes 中的一种 Ingress Controller 实现，使用 APISIX 作为数据面代理组件， 支持通过 Ingress，自定义 CRD，Gateway API 等方式进行代理规则的配置。 同时也提供了与服务注册和发现组件的集成，可以方便的与服务发现组件进行联动。 将注册在其中的服务代理出来，提供给客户端使用。
这一节将具体进行介绍。
APISIX 对服务发现的支持
APISIX 是一个高性能，全动态的云原生 API 网关，提供了 80+ 开箱即用的插件，涵盖了绝大多数用户的使用场景，其中一个很优秀的能力就是与服务发现组件的集成。
APISIX 可以和以下服务发现组件进行集成使用：
- Consul
- DNS
- Eureka
- Nacos
仅需要在 APISIX 的配置文件中添加如下配置即可（以 DNS 为例）：
1discovery:
2 dns:
3 servers:
4 - "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 为例：
1discovery:
2 dns:
3 servers:
4 - "10.96.0.10:53"创建 ApisixUpstream 资源，它的 discovery 相关的配置根据实际情况进行修改，比如此处设置了 type: dns 和具体要代理的 serviceName:
1# httpbin-upstream.yaml
2apiVersion: apisix.apache.org/v2
3kind: ApisixUpstream
4metadata:
5 name: httpbin-upstream
6spec:
7 discovery:
8 type: dns
9 serviceName: httpbin.default.svc.cluster.local最后创建一个 ApisixRoute 资源，它的 upstreams 引用刚才创建的 ApisixUpstream 资源即可：
1# httpbin-route.yaml
2apiVersion: apisix.apache.org/v2
3kind: ApisixRoute
4metadata:
5 name: httpbin-route
6spec:
7 http:
8 - name: rule1
9 match:
10 hosts:
11 - local.httpbin.org
12 paths:
13 - /*
14 upstreams:
15 - name: httpbin-upstream将上述资源都正确创建后，通过 local.httpbin.org 访问，即可访问到 DNS 中已经注册了的 httpbin.default.svc.cluster.local 了。
收益和展望
通过这种集成，对于已经使用了服务注册发现组件的用户场景，可以非常方便的通过 APISIX Ingress 将其中的服务暴露给客户端使用。
大多数 Ingress Controller 都是没有提供这种集成方案的，这也可以增加 APISIX Ingress 的应用场景。
希望 APISIX Ingress 可以更好的满足用户实际业务场景的需求。