作者：杨翊

项目简介

ApacheAPISIX

APISIX+Dubbo+Nacos 最佳实践

Apache APISIX 是 Apache 软件基金会下的云原生 API 网关，它具有多渠道支撑、精细化路由、运维友爱和插件支撑的长处特色。

  1. 多渠道支撑：APISIX 供给了多渠道处理方案，它不但支撑裸机运行，也支撑在 Kubernetes 中运用，还支撑与 AWS Lambda、Azure Function、Lua 函数和 Apache OpenWhisk 等云服务集成。

  2. 精细化路由：APISIX 支撑运用 NGINX 内置变量做为路由的匹配条件，用户可以自定义匹配函数来过滤恳求，匹配路由。

  3. 运维友爱：

  • 全动态才能：APISIX 支撑热加载，这意味着用户不需求重启服务就可以更新 APISIX 的装备。请访问为什么 [Apache APISIX 挑选 Nginx + Lua 这个技术栈]以了解完成原理。

apisix.apache.org/zh/blog/202…/

  • 生态友爱：APISIX 支撑与以下工具和渠道集成：HashiCorp Vault、Zipkin、Apache SkyWalking、Consul、Nacos、Eureka。经过 APISIX Dashboard，运维人员可以经过友爱且直观的 UI 装备 APISIX。
  1. 多言语插件支撑：APISIX 支撑多种开发言语进行插件开发，开发人员可以挑选拿手言语的 SDK 开发自定义插件。APISIX 于 2022 年 1 月 适配 Nacos 作为其注册中心用于发现后端服务，几乎一起 APISIX 支撑 Dubbo 协议署理，即支撑 HTTP 协议转 Dubbo 协议，以完成对 Dubbo 服务的直接调用。

Apache Dubbo

APISIX+Dubbo+Nacos 最佳实践

Apache Dubbo 是一款 RPC 服务开发结构，用于处理微服务架构下的服务办理与通讯问题，官方供给了 Java、Golang 等多言语 SDK 完成。比方 Dubbo-go 社区便是最新比较活跃的一个新社区。

Dubbo 具有了开箱即用、大规模布置、高度可扩展的长处，一起也具有必定的微服务办理的才能。

  1. 开箱即用：
  • 易用性高，如 Java 版别的面向接口署理特功用完本钱地透明调用。
  • 功用丰厚，根据原生库或轻量扩展即可完成绝大多数的微服务办理才能。

  1. 面向超大规模微服务集群规划：极致功用，高功用的 RPC 通讯协议规划与完成，横向可扩展，轻松支撑百万规模集群实例的地址发现与流量办理。

  2. 高度可扩展：

  • 调用过程中对流量及协议的拦截扩展，如 Filter、Router、LB 等。
  • 微服务办理组件扩展，如 Registry、Config Center、Metadata Center 等。
  1. 微服务办理：Dubbo 有一些默许的路由等才能，一起也供给了 dubbo-admin 这样的微服务办理控制台，供给给用户简略的微服务办理功用。

Dubbo 早期版别就将 Nacos 作为注册装备中心运用，两者严密结合运用已成为用户的一致。

Alibaba Nacos

APISIX+Dubbo+Nacos 最佳实践

Alibaba Nacos 是 Dynamic Naming and Configuration Service 的首字母缩写，目标是构建一个更易于构建云原生应用的动态服务发现、装备办理和服务办理渠道，具有 简略易用，特性丰厚，超高功用，超大容量，高可用的优势，Nacos 生态支撑一切主流编程言语、RPC 结构和网关，包括 Dubbo 和 APISIX。

Nacos 从 2018 年开源以来经历了 3 个大的版别，从 0.X 的初露端倪，到 1.X 的生产可用；而随着 Nacos 开源社区的发展现已用户的增多，和用户规模的逐渐增大，社区发现 Nacos 1.0 根据 HTTP 的架构开端露出一些功用问题，于是新增了 gRPC 作为更高效的通讯方法，一起对内核架构做了很多重构和更新，将功用和扩展性提高了 10 倍。一起 Nacos 2.0 也在活跃进行插件化改造，让 Nacos 的架构愈加易于拓宽和更新，变得愈加易用和愈加可以适应不同用户的不同需求。咱们首先引荐我们运用 2.X 版别来进行运用。

APISIX+Dubbo+Nacos 最佳实践

Nacos 2.X 架构层次如上图，它比较 Nacos 1.X 的最首要改变是：

  1. 客户端和服务端之间绿色部分的通讯层和衔接层，添加了 gRPC 长链接协议，一起也将会弥补客户端和服务端之间的流量控制和负载均衡。

  2. 将添加一些可拓宽的接口，完成一些插件，比方将来会完成的的装备加解密，多数据源支撑；还有将现在的鉴权笼统成插件完成；还有现在的 MCP 和 XDS 协议的支撑。

APISIX+Dubbo+Nacos 最佳实践

关于 Nacos 的生态环境，能支撑现在绝大多数开源微服务生态产品；比方 RPC 结构，即支撑阿里自身的 Dubbo，Sofastack， 也支撑像头条的 kitex，社区火爆的gRPC 等；在网关方面，有 Spring Cloud系统的 SC gateway， zuul，也有阿里自身的 tegine，还有 Mesh火爆的 Envoy，当然还是有今日分享主题内容的 APISIX；另外在应用结构层面， Nacos 也能支撑 spring 系统，包括 boot， cloud，一起也有社区很火爆的 Dapr 的适配；高可用结构方面， 分布式业务 seata 和熔断限流的 sentinel 也都在运用 Nacos 做装备办理和服务发现；最后在 Mesh 探究方面， Nacos 可以经过 mcp 协议，与 istio 互通，帮助 istio 发现服务，也支撑 coreDNS 和 confd，融入 K8s 系统。

Nacos 社区也还会不停的扩大相关的生态图谱，打造一个互联互通的 Nacos 微服务生态。

最佳实践

开端介绍最佳实践之前，请我们可以现象一下， 如果想要将让用户的进口南北向流量经过网关转发到 Dubbo 进行一系列微服务的调用，需求如何布置咱们的架构？

Dubbo 自身可以用 Nacos 做服务发现，进行服务调用；只需简略让网关从 Nacos 中获取到 Dubbo 的服务列表，然后依照 url 转发是不是就就行？

其实不是的，在实践中，通常会遇到下面 2 个首要问题：

APISIX+Dubbo+Nacos 最佳实践

首先，除掉少量自研的网关，大多数网关露出出来的服务，通常都是 HTTP 或许 HTTPS 协议的，而 Dubbo 服务通常运用 Dubbo 协议来进行通讯的。这就有一个协议转化的问题；而大多数网关并不具有，HTTP 协议和 Dubbo 协议相互转化的才能。

其次，网关需求从注册中心中获取 Dubbo 的服务列表和对应的 provider 列表；但很多网关甚至都不具有动态获取后端 RS 的才能，更别说从注册中心中获取了。

一般处理方案

处理上述问题的一般处理方案，通常是在网关和 Dubbo 服务之间，添加一层适配层，或许叫胶水层，露出 HTTP 的接口，将信息转化成 Dubbo 协议，然后在调用实际的 Dubbo 服务。

一起还需求针对网关，开发对应的网关插件，以支撑网关从 Nacos 中动态获取和刷新装备服务地址的才能。如果网关并不支撑插件才能，还需求对其源码进行改动。

APISIX+Dubbo+Nacos 最佳实践

一般处理方案尽管可以处理前面说到的两个问题，但是其也会引进一些其他的问题：

  1. 适配层会导致调用的服务多了一次流量转发，RT 和稳定性都会受到影响，比方适配服务功用缺乏了，呼应慢了，或许适配服务挂了的情况。一起适配层服务或许需求额定布置在一批服务器上，或许导致更高的本钱。

  2. 网关和适配服务，适配服务和底层服务之间也需求经过注册中心来进行注册和发现，多一层服务，或许会导致 Nacos 的订阅量翻倍，也或许需求提高 Nacos 的集群规格，导致一部分提高的本钱。

  3. 针对网关的额定插件开发或源码改动，或许需求投入必定人力进行高难度开发，究竟大多数网关的开发言语都是 C/C++/Lua 等，后续还需求投入人员保护。

综上所述，一般的处理方案，不只需求投入人力进行额定的高难度开发，还对稳定性，呼应速度，本钱有必定的影响。

APISIX+Dubbo+Nacos 最佳实践

运用 APISIX+Dubbo+Nacos，则可以完美契合咱们对这个实践的最初设想，即网关直接调用 Dubbo 服务，且直接从注册中心中获取服务地址主动更新路由。用户不需求额定考虑中间的转化以及服务发现的问题，只需求专心于开发自己的 Dubbo 业务即可。

APISIX+Dubbo+Nacos 最佳实践

因为 APISIX 原生支撑 HTTP 和 Dubbo 协议的转化，不需求适配层来帮忙，完成最简略的直接调用 Dubbo 服务。一起因为 APISIX 原生支撑将 Nacos 作为 upstream（也便是后端服务的）注册中心来源，支撑动态刷新 RS 列表。

笔者编写了一个简略的工程 Demo 来模仿最佳实践的运用结果。

github.com/KomachiSion…

整个实践过程，仅需求 4 个步骤：

  1. Clone 工程 Demo 到本地环境；

  2. 履行 docker-compose 指令，主动布置 APISIX 以及 Nacos；

  3. 发动 Dubbo 样例，可在 Nacos 上查看到注册的服务；

  4. 调用 APISIX 的 openAPI， 创建流量的 Dubbo 路由规矩；

自此，APISIX+Dubbo+Nacos 的组合运用就现已悉数完成，经过 Demo 中的样例 uri 测验进行调用。

APISIX+Dubbo+Nacos 最佳实践

方案与展望

尽管运用 APISIX+Dubbo+Nacos，可以处理这个实践中最首要的两个问题。但是它在运用中依然还有需求进步的当地。社区中会在后续的方案和展望中持续优化。

APISIX+Dubbo+Nacos 最佳实践

路由规矩主动生成

在方才的 Demo 工程中，创建路由规矩的动作是手动经过 OpenAPI 进行创建的，如果需求路由的规矩很多，势必对运维人员有较高的要求；一起保护这些 uri 和后端服务的映射联系，也是一个比较麻烦的工作。

后续社区间是否能进一步的协作，Dubbo 的元数据实际上都存放在 Nacos 中，而 APISIX 是否能经过读取这部分信息，依照必定的规矩主动生成这份路由规矩，免去用户自行创建和保护路由规矩的或许。

Mesh 探究

当前 Service Mesh 是开源社区中一个很抢手的方向，3 个社区也都在活跃进行 Mesh 化的探究；例如 Nacos 就在 3.0 中规划将 Mesh 化作为首要的演进方向，直接支撑 XDS 协议；Dubbo 3 也在进行 Mesh 化改造，一起也支撑 XDS 协议；而 APISIX 现已支撑作为 Ingress Controller 来运用；将来 3 个社区产品获取能经过 Mesh 的方法，愈加严密的结合运用，供给更多更丰厚的功用。

作者介绍：

杨翊，Alibaba Nacos PMC、Apahce ShardingSphere PMC