10大亮点！带你多角度了解云原生API网关Apache APISIX 3.0预览版

API 网关作为一个存在时间比较长的基础组件，一直致力于提供业务层面的限流限速、身份认证、可观测性等多方面的功能。

随着服务端系统的迭代，越来越多的服务开始从裸金属迁移到了 K8s 中，原来的单体架构也逐渐进化为微服务架构，同时企业也开始将一些私有化机房部署到多云和混合云场景中来。

随着这些大环境的技术变更，业务层面对于 API 网关的需求也开始逐渐复杂。

API 网关 Apache APISIX

Apache APISIX 在产品诞生之际，就希望能够在云原生和微服务的技术环境下，帮助企业解决一些新的问题。比如通过全动态特性将业务的流量进行自动扩缩容、通过一次性修改进行更方便地集群化管理等。

因此 APISIX 在架构设计上，就采取了数据面与控制面分离的模式，实现了全动态和集群化管理，这些都主要得益于 etcd 组件的作用。

APISIX 会将相关的路由配置和插件配置等都放置在 etcd 内进行存储和管理。如上图所示，右侧控制面（Control Plane）的数据都存放在 etcd 中，而左侧的数据面（Data Plane）则主要是监听 etcd 的变更，快速感知其变化，无需修改其他配置文件。

但是只解决了这些问题还是不够的。作为对上下游都有承接需求的中间件来说，API 网关大多数时候都是在企业架构中起到了流量入口和承上启下的关键位置。这个位置就决定了它不会像数据库一样，只接收来自用户业务层面的需求。

除了业务层面需求外，API 网关也会存在类似二次开发这种定制或集成需求。如何让开发者在使用 APISIX 时能更轻松地实现自定义开发，这就是 APISIX 解决的第三个痛点，即让开发者的使用门槛降得足够低。

在 APISIX 里，插件的开发主要是通过 Lua 语言来完成，通过 LuaJIT 去保证编译后的代码性能足够好。但 Lua 作为一个相对小众的语言，对绝大部分后端工程师而言学习成本略高。为此，APISIX 通过两种方式来解决这个问题。

第一种方式就是通过 Runner Plugin 来支持更多的主流开发语言，比如 JAVA、Python/ target=_blank class=infotextkey>Python、Go 等。如果你是一个后端工程师，至少应该会其中一种语言，那么这个时候你就可以非常方便地通过本地 RPC 通信，使用你之前熟悉的计算语言去开发一个 APISIX 插件。

这样做的好处是减少了开发成本，提高了开发效率。当然弊端就是在性能层面有一些损失。那么，有没有一种既能达到 Lua 原生性能，同时又兼顾高级语言的开发效率方案呢？

这里就引出了第二种方式，也就是上图左侧部分。WebAssembly 最早是用在前端或浏览器上的一个技术，在服务端它也逐渐展示出来它的优势。

把 WebAssembly 嵌入到了 APISIX 里，用户就可以使用 WebAssembly 去编译成 WebAssembly 的字节码在 APISIX 中运行。最终达到的效果就是利用高效率，开发出了一个既有高性能又使用高级计算语言编写的 APISIX 插件。

所以在目前的 APISIX 版本中，用户可以使用 Lua、Go、Python 和 Wasm 等多种方式，基于 APISIX 编写自定义代码。通过这样的方式，降低了开发者的使用门槛，也为 APISIX 的功能提供了更多的可能性。

得益于 APISIX 的架构和性能优势，从诞生到现在三年多的时间内，APISIX 在全球范围内的用户发展速度远超预期。比如 wps、新浪微博、爱奇艺等国内大厂，这些都是每天承载几百亿次 API 调用的企业用户。在海外也有像 NASA、欧盟数字工厂、瑞士电信等类似科研机构领域的用户在使用。

APISIX 3.0 新增的 10 大亮点

APISIX 在 2022 年初就提出了全新的 3.0 Roadmap，在 3.0 版本中将重点在易用性和生态系统等方面进行迭代与更新。

目前 APISIX 已正式推出 3.0 预览版，在此也选取了如下十个亮眼功能，进行一个简单的功能介绍。

1.全面支持 ARM64

目前 ARM64 对于云厂商来说，已成为一个非常主流的服务器架构选型。从 AWS Graviton、GCP Tau T2A 再到华为鲲鹏等系列产品，可以看到各家云厂商都开始推出了基于 Arm 架构的服务器。

目前从数据来看，Arm 架构的服务器在性价比层面的表现略优于 x86。为了顺应时代技术潮流，APISIX 也在 ARM64 上做了全面的 CI 回归。保证用户在 Arm 架构中运行 APISIX 时，依旧可以顺畅运行各种功能。

2.新增 gRPC 客户端

在 3.0 版本中，将新增一个 core.grpc 模块。如果你熟悉 Nginx 和 OpenResty 的话，就知道这两者对于 gRPC 的支持相当有限，仅停留在执行反向代理或负载均衡这样的基础功能上。

而 APISIX 在目前 2.x 版本中就已经实现了 gRPC 和 HTTP 协议的转换。在 3.0 版本中，将通过新增 gRPC 客户端的方式，允许开发者直接调⽤第三⽅的 gRPC 服务，⽆需引⼊额外的组件或要求服务提供⽅额外使⽤ HTTP 接⼝，将使用过程大大简捷化。

3.重新设计 Admin API

目前在使用 APISIX 时，你可能会发现 APISIX 的响应体中掺杂了很多没有意义的数据，比如一些 etcd 的返回值，没有进行任何剪裁就直接传送给了客户端。同时目前整个响应体的架构设计也并不完善，存在一些冗余字段。

在 APISIX 3.0 版本中，重新设计了响应体结构，新的格式可以让整个请求格式和返回体都更加的 Restful 化，从而让用户更加方便地使用新版本的 Admin API。当然该过程也允许通过参数来控制使用哪个版本的 Admin API，不用害怕升级后兼容不了之前的版本。

4.DP 和 CP 分离

APISIX 在最近一两年内出现了多个安全相关的漏洞，大多数漏洞的根本原因都是因为 APISIX 在默认部署模式下，将数据面与控制面部署在一起了。一旦数据面上存在安全漏洞，攻击者就可以通过数据面直接侵入控制面，从而影响到其他所有的数据面。

因此在 3.0 版本中，新增了部署模式配置deployment，默认属性为traditional，也就是数据面与控制面部署在一起。当然，新配置模式还是更建议大家将属性设置为data_plane或control_plane，从而实现数据面与控制面的完全分离。

在完全分离后，不仅能解决上述安全隐患，还能更好地在数据面和控制面中分别进行功能的迭代而互不影响。

5.更完善的服务发现支持

APISIX 在现版本中，已支持集成了很多服务发现组件，比如 Zookeeper、Consul、Nacos 等。但目前这些集成都是在数据面上完成的，一旦你的数据面节点非常多，这对于后续的服务发现组件压力也是非常大的。尤其是像 etcd 和 ZooKeeper 这一类提供强一致性的组件，通常无法承受太大量的连接数；此外，用户还需要为 Apache APISIX 数据面配置服务发现组件的认证，如果你在使用虚拟机部署 Apache APISIX，那么你需要将认证配置同步到每一个实例。

同时在用户实际生产环境中，他们想要的不仅仅是一个简单的类似于像 Consul KV 的集成或者是 DNS 的集成，而是更希望能做到类似健康检查等更多完整功能的集成。

因此在 APISIX 3.0 中，我们通过新增一个子项目APISIX-SEED进行了一层抽象，实现了控制层面的服务发现支持，降低了对服务发现组件的压力。后端服务的节点将由APISIX-SEED组件进行更新然后同步到 etcd，最终被 Apache APISIX 所使用。

6.新增 xRPC 框架

APISIX 在现版本中支持代理 TCP 协议，但是有些时候，纯粹的 TCP 协议代理是不够的。用户需要的是特定应用协议的代理，比如 redis Proxy、Kafka Proxy 等。因为有些功能必须在对该协议进行编解码之后才能实现。

因此，APISIX 在 3.0 版本中实现了一个名为 xRPC 的四层协议拓展框架，允许开发者在上面自定义特定的应用协议。基于 xRPC，开发者可以通过 Lua 代码对请求和响应进行编解码，进而在了解协议内容的基础上完成故障注入、日志上报、动态路由等功能的实现。

基于 xRPC 框架，APISIX 可以提供对若干主流应用协议的代理实现。同时用户也可以基于该框架来支持自己私有的基于 TCP 的应用协议，使其具备类似 HTTP 协议代理的精准颗粒度的和更高阶的七层控制。而在不同的协议之上，又可以去抽象一些共性因素，实现相关插件能力，让不同的协议可以共享这些能力。

7.支持更多四层可观测性

APISIX 在可观测性的功能支持上一直都投入很多，几乎支持了所有的可观测性组件，比如 Zipkin、Apache SkyWalking、Datadog 等等。同时还支持了各种各样的日志组件，但这些大多都是在七层（应用层）进行的。

在 APISIX 3.0 版本中将会增加更多基于四层（传输层）的可观测性支持。比如增加了四层上对于 Prometheus 和各种日志的支持，不仅可以让用户非常轻松地观测到七层流量中哪里出了问题，也可以去发现四层的流量运作状况。

8.集成 OpenAPI 规范

API 其实是一个涉及从开发、测试、上线到整个全生命周期的元素。在 APISIX 3.0 版本中，将支持标准的 OpenAPI 3.0 规范。

因此，如果你是在一些 API 设计和测试的软件上进行管理 API 的话，就可以非常方便地通过数据导出和导入，将其放置在 APISIX 中进行管理和维护。同时 APISIX 中的各种 API 也可以通过 OpenAPI 3.0 规范进行导出，然后再导入到其他系统中使用。

除此之外，在 3.0 版本中 APISIX 也支持了针对 Postman 相关自定义格式的支持（Postman Collection Format v2），实现两者之间的数据传输，从而更方便地进行集成。

9.Gateway API 的全面支持和服务网格

在 APISIX Ingress 的版本迭代中，已开始对 Gateway API 进行支持，最新的 1.5 版本中已基本支持了所有的 Gateway API 配置。

由于 Kube.NETes Ingress 资源本身的限制，南北向场景中很多的流量管理能力无法被很好的表达出来，因此市场上大量的 Ingress Controller 解决方案都提供了自定义的 CRD，虽然这样能很好地帮助用户管理流量，但是却间接提高了迁移的成本，几乎导致用户被某个 Ingress Controller 选型锁定。因此 Kubernetes 社区在前两年开始着手制定 Gateway API 这一标准。

Gateway API 是一个面向角色分层的协议，通常像 AWS、GCP 这样的云厂商会充当基础设施提供者，他们会提供若干种不同可选的网关选型（GatewayClass）；而网关管理员，通常会创建不同的网关实例（Gateway）；更上层的开发者则只聚焦于如何创建路由来暴露自己的 API，而不关心底层的网关细节。

这种情况下就可以通过 APISIX Ingress 去使用 Gateway API 的方式进行各种配置，也就意味着你能够在各个不同的数据面进行切换。在今年年底，APISIX Ingress 将更加完整地支持 Gateway API 以及支持在四层和七层的更多能力。

与大多数服务网格方案不同，APISIX 的服务网格方案更有优势的地方是数据面（得益于 APISIX 本身的高性能），因此在控制面的选择上，更希望去兼容一些社区上已有的主流方案。最终采取了通过使用 xDS 协议与 Istio 进行交互，并将获取到的配置写入到 APISIX 的 xDS 配置中心的方式，来配合 APISIX 生成具体的路由规则，完成对应请求的路由。

这种方案不仅可以让整个服务网格更加轻量，同时借助于 APISIX 的高拓展性，也可以进行更方便地二次开发与迁移。

10.集成更多生态

除了上文提到的 OpenAPI 标准之外，3.0 版本中也会新增非常多的生态插件，比如 OpenFunction、ClickHouse、Elasticsearch、SAML 和 CAS 等，去集成更对关于认证鉴权、安全或者可观测性等。

其中一个有趣的插件workflow是关于流量调度的， 通过该插件就可以在流量控制层面进行一些更细粒度的处理。

比如当条件 A 成立时执行某个行为，条件 B 成立时执行另一个行为等。通过这种更加清晰的方式，让用户更加方便地调度各种业务流量。

总结

不管是 APISIX 从零开始发展到现在，还是已经推出预览版的 3.0 版本，你会发现 APISIX 其实并没有在架构层面进行太多的调整与改动，更多的是进行生态、兼容性和产品应用层面的改变。

一个开源项目的评判标准，或许并不只有性能和功能，而是需要更多站在用户、开发者和企业的角度，去考虑他们使用这个产品是否可以快速有效地解决当下的痛点。

而本文中提到的亮点或者新特性，其实都是通过开源社区的大环境，接收了来自不同开发者或者企业用户的反馈而打造出来的，是他们让开源产品更加实用和充满活力。

最后，也欢迎大家对 APISIX 3.0 预览版进行体验和反馈，期待技术与社区所迸发的技术魅力。