Ming Wen 

API网关长期以来一直是一个重要组件。它致力于提供各种功能，如速率限制、身份验证（例如，使用Keycount保护API）和业务级别的可观察性。

随着服务器端技术的迭代，越来越多的服务开始从裸机迁移到Kubernetes，原来的单片架构逐渐演变为微服务架构。与此同时，企业已开始将其本地数据中心迁移到多云或混合云。

随着环境中的这些技术进步，业务层对API网关的需求变得越来越复杂。

API网关Apache APISIX

Apache APISIX诞生于帮助企业解决云原生环境和微服务中的新问题。例如，它通过全动态特性和一次性修改提供业务流量的自动缩放，以更方便地实现集群管理。

因此，在APISIX的架构设计中，数据平面和控制平面是分离的，以实现完全动态和集群管理，这主要由etcd组件完成。

在APISIX中，插件主要通过Lua开发，LuaJIT（Lua的实时编译器）用于确保编译的代码性能足够好。然而，作为一种相对次要的语言，Lua的学习成本对于大多数后端工程师来说都很高。为了解决这个问题，APISIX提供了两种解决方案。

APISIX在etcd中存储和管理路由相关和插件相关的配置。如上图所示，Admin API（控制平面）中的配置存储在etcd中，而左侧的数据平面主要监视etcd的更改。数据平面可以快速观察更改，而无需修改配置文件。

但仅仅解决这些问题是不够的。作为一个具有来自上游和下游请求的中间件，API网关作为流量入口和服务层之间的连接在企业架构中扮演着至关重要的角色。API网关的角色不同于仅接收用户业务级别请求的数据库。

除了业务级需求，API网关还需要定制和集成。因此，在使用APISIX时，如何让开发人员更容易进行定制开发是APISIX解决的另一个重要痛点，这降低了开发人员编写代码的门槛。

支持更多编程语言​

第一种解决方案是支持更广泛使用的编程语言​​（如Java、Python、Go等）。如果你是一名后端工程师，你至少会其中一种语言。使用Plugin Runner，后端工程师可以通过本地RPC进行通信，使用他们熟悉的编程语言开发APISIX插件。

这样做的好处是降低开发成本并提高开发效率。缺点是性能损失。那么，有没有一种方法可以使用开发人员熟悉的高级语言来实现Lua近乎原生的性能？

支持WASM​

第二种解决方案是使用Wasm开发插件，如上图左侧所示。Wasm（WebAssembly）最初是作为一种在浏览器中运行的新型技术使用的，但现在它在服务器端也逐渐显示出其优势。

我们将Wasm嵌入到APISIX中，用户可以使用Wasm编译Wasm字节码以在APISIX运行。此外，为了使用Wasm，我们开发了一个Wasm插件，用户可以使用高级编程语言建立接近本地的APISIX插件。

因此，用户可以使用Lua、Go、Python、Wasm等在APISIX上编写自定义插件。此外，简化开发为APISIX插件开发打开了大门。

得益于APISIX的架构和性能优势，APISIX自成立以来的三年中，全球用户增长远超预期。例如，WPS、新浪微博和爱奇艺等中国大型科技公司都是企业级用户，每天都会发送数百亿个API请求。此外，NASA和欧洲工厂平台等科研机构正在使用APISIX。

APISIX 3.0的10个新亮点​

APISIX于2022年初提出了新的3.0路线图。在3.0版本迭代和更新将集中于可用性和生态系统。

APISIX计划在9月底前推出测试版3.0。在这里，我们选择了以下十个引人注目的功能，在正式发布之前进行简要介绍。

完全支持ARM64​

ARM64已经成为云制造商非常主流的服务器架构选择。从AWS Graviton、GCP Tau T2A到华为鲲鹏等产品，我们可以看到各种云厂商已经开始推出基于Arm架构的服务器。下图显示了APISIX在流行的基于Arm的服务器上的压力测试性能：

根据目前的数据，基于Arm的服务器的性能略好于x86的性能。为了顺应时代的技术趋势，APISIX还对ARM64进行了全面的CI回归测试，以确保用户在Arm架构中运行APISIX时仍能顺利运行各种功能。

添加gRPC客户端​

在版本3.0中，Apache APISIX将支持新的core.grpc模块。然而，如果您熟悉NGINX和OpenResty，您应该知道它们对gRPC的支持非常有限，只提供了反向代理或负载平衡等基本功能。

APISIX已经在当前2.x版本中实现了gRPC和HTTP协议之间的代码转换。在版本3.0中，ApacheAPISIX将添加一个新的gRPC客户端，允许开发人员直接调用第三方gRPC服务，而无需引入额外的组件或要求服务提供商使用不同的HTTP接口，从而使过程更加简单。

重新设计管理API​

今天使用APISIX时，您可能会发现APISIX的响应体中混杂了大量无意义的数据，例如一些etcd返回值，这些值直接传递给客户端，而无需任何调整。此外，整个响应机构的架构设计并不理想，有许多冗余字段。

在APISIX 3.0版本中，响应体的结构得到了改进。此外，新设计使整个请求格式和返回体更加RESTful，使用户更容易使用最新版本的Admin API。当然，这个过程还允许您通过参数设置要使用哪个版本的Admin API，从而让用户不用担心升级到不兼容的版本。

数据平面（DP）和控制平面（CP）分离​

APISIX在过去两年中遇到了几个与安全相关的漏洞。大多数漏洞的根本原因是DP和CP以默认部署模式一起部署。因此，一旦数据平面上存在安全漏洞，攻击者就可以通过DP直接入侵CP，从而影响所有其他DP。

因此，在3.0版中，支持部署模式配置，默认部署模式是传统的，其中DP和CP一起部署。当然，新的部署模式建议您将属性设置为data_plane或control_plane以将它们分开。

当它们分离时，不仅可以解决上面提到的安全风险，而且DP和CP上的功能迭代也更易于管理，而不会相互影响。

改进的服务发现支持​

在当前版本中，APISIX支持许多服务发现组件的集成，如Apache ZooKeeper、Consul、Nacos等。但目前，这些集成都是在数据平面上完成的。一旦DP上有很多节点，就会给以下服务发现组件带来很大压力。同时，在用户的实际生产环境中，他们需要一个简单的集成，如Consul KV或DNS集成，以及健康检查等功能的完整集成。

因此，在APISIX 3.0中，我们通过添加子项目APISIX-SED来添加抽象层，以在控制平面级别实现服务发现支持，并减轻服务发现组件的压力。