You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@apisix.apache.org by bz...@apache.org on 2022/01/21 06:17:59 UTC
[apisix-website] branch master updated: docs: add xPRC details blog (#850)
This is an automated email from the ASF dual-hosted git repository.
bzp2010 pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/apisix-website.git
The following commit(s) were added to refs/heads/master by this push:
new d2b56c0 docs: add xPRC details blog (#850)
d2b56c0 is described below
commit d2b56c0fb3dd2ee0fe2c6f7f57ac1f2b67951594
Author: Sylvia <39...@users.noreply.github.com>
AuthorDate: Fri Jan 21 14:07:25 2022 +0800
docs: add xPRC details blog (#850)
---
.../01/21/apisix-xrpc-details-and-miltilingual.md | 141 +++++++++++++++++++++
.../01/21/apisix-xrpc-details-and-miltilingual.md | 135 ++++++++++++++++++++
2 files changed, 276 insertions(+)
diff --git a/website/blog/2022/01/21/apisix-xrpc-details-and-miltilingual.md b/website/blog/2022/01/21/apisix-xrpc-details-and-miltilingual.md
new file mode 100644
index 0000000..702dcfc
--- /dev/null
+++ b/website/blog/2022/01/21/apisix-xrpc-details-and-miltilingual.md
@@ -0,0 +1,141 @@
+---
+title: "xRPC Will Be Released, Get More Details About APISIX Ecosystem"
+authors:
+ - name: "Jinchao Shuai"
+ title: "Author"
+ url: "https://github.com/shuaijinchao"
+ image_url: "https://avatars.githubusercontent.com/u/8529452?v=4"
+ - name: "Sylvia"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- Multiple protocols
+- Apache APISIX
+- Java
+- Multilingual
+- Ecology
+description: This article brings you Apache APISIX's upcoming xRPC framework and related details, as well as a detailed presentation of Apache APISIX in multi-language development support.
+tags: [Technology,Ecosystem]
+---
+
+> This article brings you Apache APISIX's upcoming xRPC framework and related details, as well as a detailed presentation of Apache APISIX in multi-language development support.
+
+<!--truncate-->
+
+As business scenarios and requirements become more complex and diverse, more and more standards and protocols are emerging, and Apache APISIX, as a top open source project of the Apache Foundation, has been actively participating in and promoting the expansion of related ecological aspects.
+
+In this article, we will bring you examples of Apache APISIX's upcoming xRPC framework and multilingual plug-ins from two perspectives: **multi-protocol proxy and multilingual support**.
+
+## Multiprotocol Proxy
+
+In Apache APISIX, each request corresponds to a Route object. There are currently two main proxy scenarios for Apache APISIX.
+
+
+
+The first is the HTTP protocol proxy, which is currently the most commonly used request proxy in APISIX. Based on the HTTP protocol proxy, Apache APISIX currently implements dozens of traffic governance capabilities, such as fine-grained flow control, security, and observability.
+
+The second is a TCP and UDP-based dynamic protocol proxy and load balancing, which provides the most basic traffic admission capabilities and link-level logging capabilities. This proxy model can proxy any TCP/UDP protocol-based requests such as MySQL, Redis, Mongo or DNS. However, since it is a TCP/UDP based proxy without upper application layer protocols, it can only get some basic information about the quaternion, so it is a little bit weaker in terms of scalability.
+
+### Why xRPC
+
+Due to the limitations of Stream Route in terms of protocol proxies, and our desire to support more application layer protocols on APISIX to serve more users and application scenarios, the xRPC framework was born.
+
+The xRPC framework makes it very easy to extend protocol capabilities, both specific and private data protocols, **with precise granularity and higher-level 7-level control similar to HTTP protocol proxies**, such as request-level observability, advanced access control, and proxy policies.
+
+### What is xRPC
+
+xRPC literally means that X is an abstract representation of a protocol resource. And RPC is what we consider all resources passing through the gateway as a process dispatch, i.e. it is a protocol extension framework. So in terms of positioning, xRPC is a base framework rather than an implementation of a specific protocol.
+
+
+
+As you can see from the above architecture, xRPC is a framework based on APISIX Core extensions. On top of this framework, users can implement different application layer protocols, such as Redis, MySQL, Mongo and Postgres. On top of the different protocols, you can abstract some common factors and implement related plug-in capabilities so that different protocols can share these capabilities.
+
+So the main role of xRPC can be summarized as: **providing access to standardized application layer protocols, supporting cross-protocol capability sharing, and allowing users to get the ability to extend custom protocols.**
+
+#### Sample Application Scenarios
+
+With the xRPC protocol framework in place, what scenarios can it address? Here are a few examples.
+
+- Example 1: Redis does not support TLS in earlier versions. If there are multiple versions of Redis in our system, and we cannot upgrade Redis in production for some reasons, but we need to add TLS capability. In this case, we can use the xPRC-based Redis Protocol to solve the above situation.
+- Example 2: When we want to limit the frequency of certain IPs or callers and want to visualize the frequency of each call source, which Redis does not support. This is perfectly solved by using the Redis Protocol, which is extended by xRPC.
+- Example 3: If you want to use MySQL to temporarily enable the slow query function, you just need to access MySQL Protocol and configure the relevant policy in APISIX, which saves you from the tedious step of logging into the instance machine by machine.
+
+Of course, there are many similar application scenarios, and we hope that after the release of the feature, you can experience and practice more in the actual application. The process of invoking xPRC is shown in the following diagram.
+
+
+
+Once the upstream services are taken over by Apache APISIX, the different upstream application services can be managed in a unified manner. Functions such as logging, monitoring, security, and troubleshooting can all be accomplished through a standardized set of policies.
+
+#### Planned Implementation Phases
+
+The current design of the Apache APISIX xRPC framework is initially divided into 5 phases.
+
+
+
+- Phase 1: Read Read data and protocol decoding.
+- Phase 2: Access Phase Access phase. Provide plug-in access function, which can realize the demand scenarios of security, flow control and access.
+- Phase 3: Proxy data forwarding and load balancing. Provides access support for custom load balancing policies and algorithms.
+- Phase 4: Send Sending data and protocol encoding.
+- Phase 5: Log Phase Logging phase. Provide plug-in access to realize the logging and logging requirements scenarios.
+
+## Multilingual Ecology
+
+In order to meet the increasingly rich and large computing language base, creating code support for multi-language environment has become the first threshold to cope with future technology development. Apache APISIX has also done a lot of exploration and practice on the road of multi-language development.
+
+For example, it has recently implemented support for WebAssembly. For details and features, please refer to the article "[Apache APISIX Embraces WASM Ecology](https://apisix.apache.org/blog/2021/11/19/apisix-supports-wasm)". Of course, the support for WASM in Apache APISIX is still experimental, and we will continue to improve the support for WASM in the future. If you are interested in this project, please feel free to contribute to the [wasm-nginx-module](https://github.com/api7/wasm-n [...]
+
+In the meantime, Apache APISIX already supports multiple development languages through the "xPluginRunner Multilanguage Plugin Runtime" before WASM support is implemented. That is, when developing APISIX plug-ins, users can write and extend APISIX plug-ins not only with Lua code, which is natively supported by APISIX, but also with their own familiar languages, such as Go, Java and Python.
+
+### xPluginRunner
+
+
+
+The implementation of xPluginRunner is shown in the figure above. The whole communication process is "before" and "after" the execution of the built-in plug-ins, APISIX will initiate local RPC requests to the plug-in runtime of each language. In the plug-in runner, the computation and policy processing within each plug-in is implemented, and the result is finally responded to APISIX for subsequent decision making based on the response result.
+
+The xPluginRunner serves as a bridge for communication with Apache APISIX, and mainly implements the parsing of private data protocols and the encapsulation and unencapsulation of RPC messages.
+
+Currently, the Apache APISIX xPluginRunner solution is in a relatively stable stage, and we know from the community feedback that some enterprises have started to try it in production environments. If you are interested in this project, you are also welcome to participate in various development language plug-in projects.
+
+- [apisix-go-plugin-runner](https://github.com/apache/apisix-go-plugin-runner)
+- [apisix-java-plugin-runner](https://github.com/apache/apisix-java-plugin-runner)
+- [apache-apisix-python-runner](https://github.com/apache/apisix-python-plugin-runner)
+
+Finally, we will show you how to develop APISIX plugins based on Java Plugin Runner with a simple Java example.
+
+### Java Plugin Runner Example
+
+First of all, when developing the plugin, we need to implement the Interface of PluginFilter. `name` method in the Interface is mainly used to identify and extract the plugin name, and `filter` method is used to filter the request (i.e., execute the plugin body logic).
+
+
+
+
+
+One additional point to note is that the `request` and `response` parameters appearing in the above code have fixed logic in the Runner (all Runners apply):
+
+1. If you want the request to continue to be forwarded and only do some policy settings (such as rewriting the request parameters, headers, etc.), you can simply manipulate the `request` object.
+2. If you want to terminate the request, you can do it with the `response` object (e.g. set the response body, response headers, status codes, etc.).
+
+:::note Note
+APISIX will terminate the current request as soon as it senses that the `response` object in the Runner has been manipulated.
+:::
+
+Once the plug-in development is completed, it is time to practice the application in APISIX.
+
+First, compile Runner and the plug-ins in the project into jar packages and configure the absolute path of the jar packages into the main APISIX configuration file in the following way.
+
+
+
+Finally, restart Apache APISIX and you are ready for the routing and plugin configuration and request validation sessions.
+
+
+
+
+
+## Summary
+
+This article brings you the upcoming release of the xRPC framework for Apache APISIX and related details, as well as a detailed demonstration of Apache APISIX in multi-language development support.
+
+The article also shows the details of Apache APISIX's multilanguage development support. It shows the ecology-oriented efforts of Apache APISIX from both the multiprotocol proxy and multilanguage support perspectives.
+
+Feel free to start a discussion in [GitHub Discussions](https://github.com/apache/apisix/discussions) or communicate via the [mailing list](https://apisix.apache.org/zh/docs/general/subscribe-guide).
diff --git a/website/i18n/zh/docusaurus-plugin-content-blog/2022/01/21/apisix-xrpc-details-and-miltilingual.md b/website/i18n/zh/docusaurus-plugin-content-blog/2022/01/21/apisix-xrpc-details-and-miltilingual.md
new file mode 100644
index 0000000..9e81a75
--- /dev/null
+++ b/website/i18n/zh/docusaurus-plugin-content-blog/2022/01/21/apisix-xrpc-details-and-miltilingual.md
@@ -0,0 +1,135 @@
+---
+title: "多协议接入框架 xRPC 发布在即，为你解读更多 APISIX 生态细节"
+authors:
+ - name: "帅进超"
+ title: "Author"
+ url: "https://github.com/shuaijinchao"
+ image_url: "https://avatars.githubusercontent.com/u/8529452?v=4"
+ - name: "苏钰"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- 多协议
+- Apache APISIX
+- Java
+- 多语言
+- 生态
+description: 本文为大家带来了 Apache APISIX 即将发布的 xRPC 框架以及相关细节，同时介绍了 Apache APISIX 在多语言开发支持中的细节展示。
+tags: [Technology,Ecosystem]
+---
+
+> 本文为大家带来了 Apache APISIX 即将发布的 xRPC 框架以及相关细节，同时介绍了 Apache APISIX 在多语言开发支持中的细节展示。
+
+<!--truncate-->
+
+随着业务场景和需求越来越复杂和多样化，越来越多的标准和协议都开始崭露头角。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 生态」](https://apisix.apache.org/zh/blog/2021/11/19/apisix-supports-wasm)文章。当然，目前 Apache APISIX 对 WASM 的功能支持还属于实验阶段，未来仍会继续完善对 WASM 的相关支持。如果您对此项目感兴趣，也欢迎积极参与到 [wasm-nginx-module](https://github.com/api7/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](https://github.com/apache/apisix-go-plugin-runner)
+- [apisix-java-plugin-runner](https://github.com/apache/apisix-java-plugin-runner)
+- [apache-apisix-python-runner](https://github.com/apache/apisix-python-plugin-runner)
+
+最后我们将通过一个简单的 Java 示例，为大家展示一下如何基于 Java Plugin Runner 来开发 APISIX 插件。
+
+### Java Plugin Runner 示例
+
+首先在开发插件时，我们需要去实现 PluginFilter 的 Interface。Interface 中 `name` 方法主要用来标识和提取插件名称，`filter` 方法则用来过滤请求（也就是执行插件主体逻辑）。
+
+
+
+
+
+需要额外注意一点，上述代码中出现的 `request` 和 `response` 两个参数在 Runner 中存在固定逻辑（所有 Runner 都适用）：
+
+1. 如果希望请求继续转发，仅进行一些策略设置（如改写请求参数、头信息等），只需操作 `request` 对象即可。
+2. 如果想要终止请求，可以通过 `response` 对象来完成（如设置响应体、响应头、状态码等）。
+
+:::note 注意
+APISIX 一旦感知到 Runner 中的 `response` 对象被操作就会立即终止当前请求。
+:::
+
+插件开发完成之后，就可以在 APISIX 中进行应用的实践了。首先将 Runner 及项目中的插件编译为 jar 包，并将 jar 包的绝对路径配置到 APISIX 主配置文件中，配置方式如下：
+
+
+
+最后重启 Apache APISIX，就可以进行路由和插件的配置及请求验证环节了。
+
+
+
+
+
+## 总结
+
+本文为大家带来了 Apache APISIX 即将发布的 xRPC 框架以及相关细节，同时介绍了 Apache APISIX 在多语言开发支持中的细节展示。通过多协议代理与多语言支持两个角度，充分展示了 Apache APISIX 在面向生态的多项努力。也欢迎随时在 [GitHub Discussions](https://github.com/apache/apisix/discussions) 中发起讨论，或通过[邮件列表](https://apisix.apache.org/zh/docs/general/subscribe-guide)进行交流。