Apache APISIX（2.11.0）引入了对WASM的支持，允许开发者使用多种编程语言通过WASM开发插件。本文探讨了为何选择Proxy WASM标准，如何在Apache APISIX中使用WASM，以及WASM在性能和多语言支持方面的优势。同时，文章也指出了WASM当前存在的局限性和未来的发展潜力。
在 Apache APISIX 版本（2.11.0）中，我们新增了对于 WASM 的支持！现在开发者除了可以使用 Lua、Java、Go、Python、JavaScript 等多种编程语言开发 APISIX 的插件之外，也可以用 WASM 来开发插件。
WASM 全称 WebAssembly，与上述具体编程语言运行时的不同之处在于，它是一套字节码标准，专门设计成可以在宿主环境中嵌套使用。
如果某种编程语言提供编译成 WASM 字节码的功能，就可以把该语言的应用编译成 WASM 字节码，运行在某个支持 WASM 的宿主环境中。
听起来，是不是只要某个宿主环境支持 WASM，就能像操作系统一样运行任意应用呢？
但其实这里有个限制，就像操作系统需要实现特定标准的 syscall 一样，要想运行特定的应用，也需要实现该应用所需的 API。
以 JavaScript 为例，虽然同样是 JavaScript 代码，但是针对浏览器写的 JS 模块不能直接用在 npm 包里面，因为两个的 API 不一样。
所以仅仅把 WASM 放到 Apache APISIX 里面并行不通，要想让开发者在 Apache APISIX 上运行 WASM，我们还需要提供一套专门的 API。
为什么选择 Proxy WASM
对于如何提供这套 API，我们曾经权衡过两套方案：
-
参考 lua-nginx-module 的接口，实现对应的 WASM 版 API
-
实现 Proxy WASM 这一套标准
Proxy WASM 是 Envoy 的 WASM API 标准。所以上述问题其实等价于，我们是自己搞一套 API 标准还是复用 Envoy 已有标准呢？
WASM API 标准可以拆成两个方面来看：
-
Host，负责提供 API 的实现
-
SDK，要想在不同的编程语言里面调用提供的 API，需要使用该语言来实现一套胶水层
如果我们遵循 Envoy 的标准，优势在于可以复用 Envoy 现有的 WASM SDK（Proxy WASM SDK），而不足之处在于这套标准是 Envoy 结合自己情况制定的，如果我们跟着实现，没有自
最低0.47元/天 解锁文章
689
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
