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

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 协议代理的精准颗粒度的和更高阶的七层控制。而在不同的协议之上，又可以去抽象一些共性因素，实现相关插件能力，让不同的协议可以共享这些能力。