关于后端:多协议接入框架-xRPC-发布在即为你解读更多-APISIX-生态细节

随着业务场景和需要越来越简单和多样化，越来越多的规范和协定都开始锋芒毕露。Apache APISIX 作为 Apache 基金会的顶级开源我的项目，始终积极参与并推动相干生态层面的扩大。

本文将从 多协定代理 与多语言反对 两个角度，为大家带来 Apache APISIX 行将公布的 xRPC 框架与多语言插件的相干示例。

多协定代理

在 Apache APISIX 中，每个申请都会对应一个 Route 对象。目前 Apache APISIX 的代理场景次要以下两种。

第一种是 HTTP 协定代理，也是目前 APISIX 中最罕用的申请代理。基于 HTTP 协定代理，Apache APISIX 目前曾经实现了数十种流量治理能力，如：细粒度的流控、平安和可观测性等。

第二种则是基于 TCP 和 UDP 的动静协定代理和负载平衡，它提供了最根底的流量准入能力和链接级别的日志能力。这种代理模式能够代理任何基于 TCP/UDP 协定的申请，如：MySQL、Redis、Mongo 或 DNS 等。但因为它是基于 TCP/UDP 的代理没有下层的应用层协定，只能获取到四元组的一些根底信息，所以在扩大能力上会稍弱一些。

为什么要开发 xRPC 框架

因为 Stream Route 在协定代理上的限度，加之咱们心愿在 APISIX 上能够反对更多的应用层协定，以服务更多用户和利用场景，xRPC 框架应运而生。

通过 xRPC 框架能够十分便捷地扩大协定能力，不论是特定还是公有数据协定，都能够具备相似 HTTP 协定代理的 精准颗粒度 的和 更高阶的 7 层管制， 比方申请级别的可观测性、高级访问控制和代理策略等性能。

什么是 xRPC

xRPC 从字面角度来剖析，即 X 为协定资源的形象代表。而 RPC 是咱们认为所有通过网关的资源都为一个过程调度，即它是一个协定扩大框架。所以在定位上，xRPC 是一个根底框架，而不是一种具体协定的实现。

从上图架构能够看出，xRPC 是基于 APISIX Core 扩大进去的框架。在该框架的根底之上，用户能够去实现不同应用层的协定，比方 Redis、MySQL、Mongo 和 Postgres 等。而在不同的协定之上，又能够去形象一些共性因素，实现相干插件能力，让不同的协定能够共享这些能力。

所以 xRPC 的次要作用能够总结为：提供标准化应用层协定的接入能力，反对跨协定的能力共享，以及让用户能够取得自定义协定的扩大能力。

利用场景示例

有了 xRPC 协定框架之后，它能够解决哪些场景呢？这里简略给大家举几个例子。

1. 示例 1：像 Redis 在晚期版本中是不反对 TLS 的。如果咱们零碎里同时存在多个版本的 Redis，同时因为某些起因临时不能在生产环境中降级 Redis，但又有减少 TLS 能力的需要。这个时候就能够基于 xPRC 的 Redis Protocol 来解决上述情况。
2. 示例 2：当咱们想对某些 IP 或者调用方做频率限度并且想直观的看到每个调用起源的调用频率，这些 Redis 本身是不反对的。此时就能够通过那通过 xRPC 扩大进去的 Redis Protocol 完满解决。
3. 示例 3：如果想利用 MySQL 长期开启慢查问性能，只需接入 MySQL Protocol 并在 APISIX 配置相干策略即可，省去了后续再一台台机器去登录实例的繁琐步骤。

当然，相似的利用场景还很多，也心愿在性能公布之后，大家多多在理论的利用过程中去体验和实际。接入 xPRC 后的调用过程如下图所示。

一旦通过 Apache APISIX 实现了上游服务的接管，就能够把上游不同的应用服务进行统一化治理。相似日志输入、监控、平安还有问题排查等性能，都能够通过一套标准化的策略来实现。

打算实现阶段

目前 Apache APISIX xRPC 框架的设计，初步划分为 5 个阶段。

• 阶段一：Read 读取数据与协定解码。
• 阶段二：Access Phase 准入阶段。提供插件接入性能，可实现平安、流控和准入等需要场景。
• 阶段三：Proxy 数据转发与负载平衡。提供自定义负载平衡策略及算法的接入反对。
• 阶段四：Send 发送数据与协定编码。
• 阶段五：Log Phase 日志阶段。提供插件接入性能，实现日志上报和记录等需要场景。

多语言生态

为了满足日益丰盛和宏大的计算语言库，打造多语言环境的代码反对成为应答将来技术倒退的第一门槛。Apache APISIX 在多语言开发的路线上也做了很多的摸索与实际。

比方在近期曾经实现了对 WebAssembly 的反对，具体实现细节与性能可参考「Apache APISIX 拥抱 WASM 生态」文章。当然，目前 Apache APISIX 对 WASM 的性能反对还属于试验阶段，将来仍会持续欠缺对 WASM 的相干反对。如果您对此我的项目感兴趣，也欢送积极参与到 wasm-nginx-module 我的项目奉献中。

同时，在对 WASM 实现反对前，Apache APISIX 已通过「xPluginRunner 多语言插件运行时」实现了对多种开发语言的反对。即在开发 APISIX 插件时，用户不仅能够应用 APISIX 原生反对的 Lua 代码去编写，也能够应用各自相熟的语言，比方 Go、Java 和 Python 等，实现对 APISIX 插件的编写与扩大。

xPluginRunner

xPluginRunner 的实现形式如上图所示。整个通信过程是在内置插件「开始执行之前」和「实现执行之后」，APISIX 会发动本地 RPC 申请到各语言的插件运行时。在插件运行时中，实现各个插件内的计算和策略解决，最初将后果响应给 APISIX，基于响应后果再进行后续的决策。

xPluginRunner 作为跟 Apache APISIX 通信的桥梁，次要实现了 公有数据协定的解析 与 RPC 报文的封包与解包。

目前 Apache APISIX xPluginRunner 的计划曾经处于比较稳定的阶段了，从社区反馈中也得悉局部企业曾经开始尝试在生产环境中利用了。如果您对此我的项目感兴趣，也欢送积极参与到各个开发语言插件我的项目中：

• apisix-go-plugin-runner
• apisix-java-plugin-runner
• apache-apisix-python-runner

最初咱们将通过一个简略的 Java 示例，为大家展现一下如何基于 Java Plugin Runner 来开发 APISIX 插件。

Java Plugin Runner 示例

首先在开发插件时，咱们须要去实现 PluginFilter 的 Interface。Interface 中 name 办法次要用来标识和提取插件名称，filter 办法则用来过滤申请（也就是执行插件主体逻辑）。

须要额定留神一点，上述代码中呈现的 request 和 response 两个参数在 Runner 中存在固定逻辑（所有 Runner 都实用）：

1. 如果心愿申请持续转发，仅进行一些策略设置（如改写申请参数、头信息等），只需操作 request 对象即可。
2. 如果想要终止申请，能够通过 response 对象来实现（如设置响应体、响应头、状态码等）。

留神：APISIX 一旦感知到 Runner 中的 response 对象被操作就会立刻终止以后申请。

插件开发实现之后，就能够在 APISIX 中进行利用的实际了。

首先将 Runner 及我的项目中的插件编译为 jar 包，并将 jar 包的绝对路径配置到 APISIX 主配置文件中，配置形式如下：

最初重启 Apache APISIX，就能够进行 路由和插件的配 置及 申请验证 环节了。

总结

本文为大家带来了 Apache APISIX 行将公布的 xRPC 框架以及相干细节，同时介绍了 Apache APISIX 在多语言开发反对中的细节展现。通过 多协定代理 与多语言反对 两个角度，充沛展现了 Apache APISIX 在面向生态的多项致力。也欢送随时在 GitHub Discussions 中发动探讨，或通过邮件列表进行交换。