WebAssembly 自我突破之路：如何构建一个跨编程语言的新生态？

作为近几年最令业界感到兴奋的新兴技术之一，WebAssembly（缩写为 Wasm）已经拓展到浏览器之外，在嵌入式和云端都有了相当广泛的使用场景。随着 Wasm 不断地被各个语言及平台所集成，使用场景日益复杂、使用的开发者越来越多，新的问题也出现了。

一般而言，开发者在开发 Wasm App 的时候，往往会使用自己熟悉的编程语言做开发，比如 C、Rust、Java 或者 Go 等等，然后利用工具链将那些 C、Rust、Java 或者 Go 应用转换为一个 Wasm Module 并运行。这个过程在应用由单个 Wasm Module 组成的时候很流畅，不会遇到问题，但是当应用中需要包含多个由不同语言编写的 Wasm Module 时，就会出现多语言屏障、工具链一致性等棘手问题，给开发者增加不少负担。

为了解决多语言多模块互通问题，Wasm 社区推出了名为 WebAssembly Component Model 的新提案，目前这是 Wasm 社区最高优先级推进的一项工作。

在 9 月 3-5 日即将召开的 QCon 北京 2023 上，Intel Web Platform Engineering 软件工程师、Wasm Micro Rumtime 项目主要贡献者何良将带来以《WebAssembly Component Model 构建一个跨语言的新生态》为主题的演讲分享。会前，InfoQ 对何良老师进行了专访，围绕 WebAssembly 技术演进和应用现状、WebAssembly Component Model 方案想要解决的问题和发展历程等话题展开探讨。

以下为访谈实录，经 InfoQ 编辑整理：

InfoQ：很荣幸有机会采访您，请您先介绍一下自己的从业经历。您是在什么时候、因为什么契机接触到 WebAssembly 的？又是如何加入 WebAssembly 社区的？

何良：我们是一个长期专注于 language runtime 的团队。早期从事 secure Java VM 的研发和优化，目前聚焦在 Node JS 和 WebAssembly language runtime 领域。我们在 Wasm 领域的项目叫做 wasm-micro-runtime。该项目启动于 2018 年，当时是 WebAssembly Post MVP。后来随着 2019 年 BytecodeAliance 成立，WAMR 项目贡献给了社区，也是最早的几款浏览器之外的 Wasm standalone runtime。除了满足通用的特性，针对嵌入式设备的特殊使用场景提供了很多定制化的特性。

WebAssembly 现状与存在的问题

InfoQ：WebAssembly 最初是为浏览器设计的，很多人对它的认识可能还是局限在浏览器，实际情况是什么样的？您认为 WebAssembly 当前处于什么样的发展阶段？

何良：WebAssembly 的使用场景已经扩展到浏览器之外，在嵌入式和云端都有广泛的使用场景。这主要得益于几个优势：由于 Wasm 运行在 sandbox 之内，天然在安全性上有优势。Wasm + WASI 的组合成为云上超轻量级的容器方案，这个方案比 docker 有更快的启动速度，更轻量的体积。另外，Wasm 语言中立的特性，可以让 Wasm 成为系统组件化（或者说插件化）的新思路，也就是将基础、稳定的底层功能以二进制形式发布，将需要快速变更、快速部署的业务逻辑代码以 Wasm 形式发布。

InfoQ：能否详细介绍一下目前 WebAssembly 在 Intel 的采用情况（包括主要在哪些业务场景下使用 WebAssembly、如何使用、带来了哪些收益或效果）？

何良：我们主要参与 Wasm spec 的制定和 language runtime 的开发。应用以嵌入式为主，也为客户提供云上方案的参考设计。

InfoQ：业界有声音认为 WebAssembly 的潜力尚未得到充分发挥，尤其在服务器端。您是否认同这一看法？在您看来，如果社区想让 WebAssembly 得到更广泛采用，有哪些问题亟待解决？

何良：是的。延续前面第二个问题的回答，Wasm 虽然有不少优点，但还没有得到足够的空间来施展。这里面的原因很多，我认为比较主要的包括：

• 工具链不丰富，不单指能够将某种开发者熟悉的语言转换为 Wasm module 的编译工具，还有调试工具和性能分析工具。

• 缺少有统治力的杀手级应用，Wasm 提供的能力更像是对现有能力的提高，而非一个解决问题的必需品，所以需要有一个有影响力的应用来做“吃螃蟹的人”。

接下来社区会重点推广的 Component Model 解决了多语言的问题，将有助于壮大 Wasm 的使用范围，将更多开发者卷入进来。

社区最高优先级工作：WebAssembly Component Model

InfoQ：您这次要分享的主题是“WebAssembly Component Model” ，那么，到底什么是 WebAssembly Component Model？原来的 WebAssembly Module 存在什么问题？为什么需要引入 Component Model？

何良：Component Model 是 WebAssembly 解决多语言多模块互通问题的方案。通常开发者在开发 Wasm App 的时候，并不会直接用“汇编语言”写。开发者往往使用自己熟悉的语言，比如 C、Rust、Java 或者 Go 等等开发，然后利用工具链将那些 C、Rust、Java 或者 Go 应用转换为一个 Wasm Module 并运行。

这个过程在应用由单个 Wasm Module 组成的时候很流畅，不会遇到问题，但是当应用中需要包含多个由不同语言编写的 Wasm Module 时，问题就出现了。

• 第一个问题是语言屏障。由于是不同的开发者用不同的语言来写 Wasm library，这里就有一个很自然的问题，如何才能让两个语言的不同类型系统互相理解，避免“鸡同鸭讲”的局面。比如 Java 要传一个 List 给 C，Rust 要传一个 Union 给 Golang。除去这些复合类型，还有一些语言特有的概念，比如 Optional、Pointer 等，不一定能在每个语言里找到对应的表示。

• 第二个问题是工具链的一致性。在 Wasm 中，两个模块的接口称为 import 和 export。import 的符号必须要和 export 的符号保持形式（比如函数签名）的一致才能成功对接。这就要求不同语言的工具链在转换 Wasm 的时候，对于逻辑上类似的类型概念要做出相同的转化，以保障在 Wasm 层面的对接能成功。也就是说，即使 Java 和 C 都说好了 List 如何用各自的语言表示，仍然需要两个工具链能够把各自的 List 的表示变化为相同的 Wasm 表示。

• 第三个问题是隔离性。如何划定主要几个 module 之间的内存范围？module 和 module dependencies 之间如果能共享线性内存，那么不同 module 的相同 dependencies 之间是否能共享线性内存？这些问题的答案似乎会随着使用场景的不同发生变化。

综上所述，当开发者需要从 Wasm Module 中分化出不同功能的 libraries，并希望用多种语言来实现复用和协作的时候，就会遇到多语言屏障。除此之外，Wasm 世界也迫切需要更强大的类型系统，来丰富 Core Wasm 的简单类型系统。

原有的 WebAssembly Module 虽然发展出了 Interface type 和 nanoprocess 的提案，但没法满足 WASI 在可移植接口上的要求。WASI 希望能同时具有模块化和基于能力模型的安全特性，这两个要求都指向了内聚，足够的内聚又引发了模块协作的问题。

InfoQ：社区是什么时候提出相关定义的？能否带我们回顾一下 WebAssembly Component Model 的发展历程（或发展路线图 RoadMap，有哪些关键节点）？目前 WebAssembly Component Model 已经是可用状态了吗？接下来的规划是怎样的？

何良：在 MVP 时代，社区已经在尝试解决多个 Wasm Module 的问题。

当时的重点是在运行时状态，也就是多个 Module Instance 在内存里的形态。比如怎么分配运行栈、怎么分配线性空间等等。主要的模型有两种，一种是类似 Linux 库之间的 shared-everyhing linking，一种是注重安全性的 shared-nothing linking。这个方向的 spec proposal 叫做 Module Linking。

另一个值得关注的 spec proposal 叫做 interface type。这个主要是为了解决 WASI 标准化。早期的 WASI 是用类 C 的语法来实现。由于早期开发者多为 Rust 和 C 的背景，类 C 的 WASI 也能工作得很好。

紧随其后，社区提出了 nanoprocess 的 vision。希望在保持内存独立的前提下， 每个 Module 都通过固定的“管道”和其他 module 协作通讯。

但随着 Wasm 被更多的开发者接受，多语言的问题逐渐变成了一个更大更迫切的问题。这里的多语言不只是从 C 增加到 Rust、C++ 这些系统语言，而且增加了 Java、Go、Koltin、Dart 等高级语言，甚至还有 JS、Python 等动态语言。再加上虚拟化、隔离等要求，社区就合并了 module linking 和 interface type，诞生了 Componet Model。

Component Model 现在是社区最高优先级推进的工作。随着 WASI Preview2 的不断推进，Componet Model 将在短时间内落地。Componet Model 本身已经具有相当的成熟度， 基本的工具链和 runtime 支持已经推出。Componet Model 正在开发的包括：增加 thread spawing 的支持、异步的支持等等。

InfoQ：WebAssembly Component Model 希望实现哪些设计目标？（有哪些关键的设计原则）

何良：主要包括这几点：遵守 Core Wasm 定义的框架；语言中立；支持 WASI 的可移植、虚拟化需求；实现隔离性（默认实现 shared-nothing linking 同时支持 shared-everything linking）；有利于浏览器支持。

InfoQ：WebAssembly Component Model 与现有的 WebAssembly 其他规范和提案，有什么区别和联系？

何良：WebAssembly Component Model 是早期两个 proposal （module linking 和 interface type）的合成和延续。不依赖 Wasm GC 的存在，不会破坏 Core Wasm 规范的设计。

InfoQ：您的演讲提纲中提到了“下一代 WASI”，如何理解 WebAssembly Component Model 与下一代 WASI 之间的关系？

何良：下一代 WASI 使用了 Component Model 提供的抽象类型系统，目的是利于更多语言实现 WASI。这也意味着为了运行使用新 WASI 的 Wasm APP， runtime 必须支持 Component Model。

Comonent Model 提供的隔离性和移植性有助于 Wasm library 实现复用和协作的目标。而 Component Model 引入的 resource、stream、异步等概念，有助于扩展 WASI 的能力。

InfoQ：在您看来，过去这两年 WebAssembly 在技术演进、社区建设、应用落地三大方面进展算快还是慢？有什么令人眼前一亮或影响比较大的里程碑事件吗？

何良：Wasm 过去在技术演进方面有很多进展。像 GC、Component Model、WASI-Thread、WASI-Socket 等重量级的提案出现了很多。在社区建设上，越来越多的开发者和落地方案在尝试、评估并使用 Wasm，这是我们乐于见到的。虽然在应用落地上还是没有出现有影响力、有话题度的案例，但我们希望培育好土壤，提供充足的阳光和养料，最后能结出硕果。

InfoQ：请您分享一下对 WebAssembly 未来发展的看法和期待？在 WebAssembly 社区重点投入的技术方向中，最令您感到兴奋的是哪一个方向？为什么？

何良：Wasm 是对很多现有技术的补充和替代。随着影响力慢慢扩大，它会得到更多的应用场景和实践。作为一门新兴的技术，Wasm 呈现出了学界和工业界对类型系统、模块化、容器化等多个领域的思考和实践总结，可以说是这些领域的集大成。

采访嘉宾介绍

何良，Intel Web Platform Engineering 软件工程师，Wasm Micro Rumtime 项目主要贡献者。长期参与 WebAssembly 社区活动和推广。

QCon 全球软件开发大会·北京站，以「启航·AIGC 软件工程变革」为主题，将于 9 月 3 - 5 日于北京·富力万丽酒店正式开幕。此次大会策划了大前端融合提效、大模型应用落地、面向 AI 的存储、AIGC 浪潮下的研发效能提升、LLMOps、异构算力、微服务架构治理、业务安全技术、构建未来软件的编程语言、FinOps 等近 30 个精彩专题。会上，何良老师将围绕《WebAssembly Component Model 构建一个跨语言的新生态》主题做进一步分享，详细解读 WebAssembly Component Model 方案和下一代 WASI 的技术新动向，敬请期待~

还有更多精彩内容，尽在 QCon 全球软件开发大会·北京站， 9 月 3-5 日三天沉浸式学习，近 30 个场热门专题，130+ 名讲师现场分享。9 月 3 日上午，7 场主题演讲还将免费对外直播，想与 LangChain 作者 Harrison 交流？那就赶快扫码预约吧！

大会报名仅剩最后 3 天，咨询购票优惠信息可联系票务经理 18514549229（微信同手机号）。