关于后端:借助-APISIX-Ingress实现与注册中心的无缝集成

3次阅读

共计 2862 个字符，预计需要花费 8 分钟才能阅读完成。

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

原文链接

微服务架构是以后最为风行的利用架构之一。
利用被拆分为多个服务组件，通过相互配合共同完成业务的具体逻辑和性能。

随着利用规模的减少和微服务拆分粒度的不同，一套零碎内会蕴含很多个服务组件。
要让这些组件之间能够很好的协同，并且能彼此辨认到，通常都须要引入服务注册和发现组件。

之前咱们写了一篇文章专门来介绍微服务架构中的服务发现，
What Is Service Discovery in Microservices – API7.ai

简略来说，__通过引入了服务发现组件，微服务架构中的组件，只须要关注其余组件的名称即可，而无需关注其余组件的部署地位，或者部署 IP 等信息。
通过服务发现组件能够动静的进行获取。__

在 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 是一个高性能，全动静的云原生 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 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 致力的指标。

正文完