API网关Apache APISIX 3.0版本正式发布！

作为开源的云原生 API 网关，Apache APISIX 致力于在性能和使用体验上为开发者和用户们带来更好更优异的表现，帮助企业解决一些关于云原生和微服务技术下遇到的新问题。

在 9 月底，Apache APISIX 发布了 3.0.0-beta 预览版，为用户们提前带来了一些新的功能体验。今天，APISIX 正式发布了 3.0.0 版本，将产品从体验和功能角度，带到了新一轮的进程中。经过迭代的 3.0.0 正式版与此前 3.0.0-beta 预览版相比：

新增了 Consumer Group，可以更方便地管理消费者；

支持配置 DNS 解析域名类型的顺序；

新增 AI 平面，更智能化地对配置与流量进行分析与呈现；

对多个现有生态插件进行更细致的优化。

除了以上技术层面的细节改动外，还有很多新的功能特性与生态扩展细节均在下文中为大家呈现。可以说这次的版本迭代，真正做到了“性能更强更智能，生态更广更多样”。

如果你想立刻体验 APISIX 3.0 正式版本，可以即刻前往官网进行下载与使用，也可点击文末「阅读原文」获取最新版本。

APISIX 3.0 新增亮点汇总

全面支持 ARM64

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

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

新增 gRPC 客户端

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

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

重新设计 Admin API

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

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

DP 和 CP 分离

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

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

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

新增 AI 平面

在数据平面和控制平面之外，Apache APISIX 新增了 AI 平面。通过对于 API 流量和配置的学习与分析，减轻开发者和维护者的使用和运维压力。比如以下两个场景就可以通过 AI 平面进行自动优化：

发现没有身份认证的 API，并给出风险提示；

对于只配置了身份认证等 Access 阶段插件的 API，自动跳过 log 等不必要阶段，加快处理速度。

AI 平面给流量处理带来了新的可能性，在后续使用过程中，类似上游服务自动热身、安全威胁发现等都可以通过 AI 平面来进行处理。

更完善的服务发现支持

APISIX 在现版本中，已支持集成了很多服务发现组件，比如 Zookeeper、Consul、Nacos 等。但目前这些集成都是在数据面上完成的，一旦你的数据面节点非常多，这对于后续的服务发现组件压力也是非常大的。

尤其是像 ETCD 和 ZooKeeper 这一类提供强一致性的组件，通常无法承受太大量的连接数；此外，用户还需要为 Apache APISIX 数据面配置服务发现组件的认证，如果你在使用虚拟机部署 Apache APISIX，那么你需要将认证配置同步到每一个实例。

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

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

新增 xRPC 框架

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

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

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

支持更多四层可观测性

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

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

集成 OpenAPI 规范

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

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

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

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

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

由于 Kubernetes 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 的高拓展性，也可以进行更方便地二次开发与迁移。

集成更多生态

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

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

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

总 结

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

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

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

审核编辑 ：李倩