Wasm 标准的演变：构建组件模型

WebAssembly (Wasm) 空间内正在进行多项新的标准化工作，包括我们认为是编写软件应用程序的新方法。通过描述这个新模型，我想深入了解 Wasm 的一些历史，以此来描述我们的前进方向。

WebAssembly (Wasm) 的设计始于 2015 年，比 2019 年正式成为第四大 Web 语言早了几年。虽然许多技术人员都熟悉 Wasm 作为一种浏览器技术，但 Wasm 本身并不依赖于 JavaScript 或 Web API。

Wasm 的前身asm.js在 2013 年崭露头角。JavaScript 的一个子集，可针对浏览器进行高度优化，并且可以充当 C 和C++ 等语言的编译目标。 “JavaScript 的诞生与死亡”是我一直以来最喜欢的演讲之一，涵盖了受asm.js启发的虚构未来。通过观看他在 PyCon 2014 上的演讲，请注意我们最终用 Wasm 和 Gary 的预测铺平的未来之间的相似之处。

我经常称asm.js是有史以来最伟大的 hack（以最有爱的方式）。谁会想到高级脚本语言可以 A")" 编译目标和 B")" 如此快得令人难以置信？ 2012 年，我将几个 C++ 库移植到asm.js中，感觉我已经解锁了一个可移植宇宙的密码。

该技术证明了几件事。首先，需要并希望将其他语言引入网络，但开发人员不想就此止步。移植的应用程序类型对计算和图形要求很高，从数据可视化工具（比如我在 SAS 工作的组件）到使用Unity和虚幻引擎构建的游戏（UE3在 4 天内移植）。

这就是为什么在 2015 年创建W3C WebAssembly 社区组和相应的 WebAssembly设计存储库时，Mozilla、 Google 、 Microsoft和Apple等浏览器供应商是这项工作的第一批贡献者，也是最先看到切实机会的人。该设计需要一种二进制格式的语言，可用作便携式编译目标，优化大小以实现快速下载，并支持流式编译，使下载的模块具有近乎即时的实例化。最重要的是，这些模块必须像在浏览器中运行的任意代码一样促进沙盒[执行环境]。

为什么 Wasm 超越浏览器？

在浏览器端部署中学到的大部分知识都为 Wasm 在浏览器之外发挥其潜力的多种方式提供了线索。 “云”在全球机器网络中构成了一组异构的计算架构、操作系统和系统约束。

将 Wasm 的一些关键属性视为可移植的编译目标，由于紧凑的二进制格式，它快速、沙盒化且易于分发。 Wasm 的这些特性使其成为云计算的完美分布式单元。此外，公司希望为不同的环境构建应用程序，但不希望每次都必须重构。 Wasm 消除了这些障碍。

当我第一次了解到asm.js时，我正在寻找一种解决方案，以便将我们现有的 Flash 应用程序转换为 HTML5。这个 ActionScript/Flex 应用程序是其 Java 对应版本的重写版本，它是用 C 编写的相同业务逻辑的早期版本的端口。如果您没有在大型企业工作过，这个故事对您来说可能看起来很疯狂，但您可以找到每个组织中每个计算时代之间的这种类型的移植，幸运地经受住了时间的考验。

Wasm 允许完全移植到任何符合 Wasm 的运行时，包括浏览器、专为 FaaS 构建的运行时，或设计用于在物联网微型架构上运行的东西。在 Web 中，Wasm 模块能够使用 JavaScript“胶水”代码访问 WebGL、网络和设备等 Web API，以完成纯计算之外的事情。归根结底，Wasm 程序实际上只对数值进行操作，或者换句话说，Wasm 模块是穿着风衣的一堆 i32。为了做有趣的事情，Wasm 模块需要能够从主机运行时调用函数。

WASI：服务器端Wasm的前沿

大约在 WebAssembly 1.0 成为推荐的 Web 标准的同时，在 W3C WebAssembly 工作组中创建了一个新的子组，用于探索 WebAssembly 的系统级接口，称为 WASI（WebAssembly 系统接口）。从那以后，该小组一直致力于创建一套标准化接口。

WASI 的存在是为了让 WebAssembly 在任何地方都能很好地工作，而不仅仅是在浏览器中，但 WASI 的关键定义特性是其基于功能的安全模型。自上世纪 60 年代以来，基于能力的安全性就一直存在（ Dennis & Van Horn，1966 年），但Dan Gohman以Cloud ABI的想法为基础，在此基础上设计了一种新的方法。

可以理解的是，这项技术很快引起了有兴趣在网络之外运行 Wasm 的公司的注意。 Fastly、英特尔、红帽和 Mozilla 等公司看到了让 Wasm 在云端、设备和边缘工作的机会。这些公司是字节码联盟 (BA) 的创始成员，字节码联盟是一个非营利组织，致力于使用 WASI 等标准为 Wasm 构建安全软件基础。许多其他组织很快加入了 BA，其中包括整个软件行业的主要参与者，它现在已经拥有 30 多个成员并且还在不断壮大！

在过去的几年里，我们在构建必要的工具以在云原生应用程序中运行 Wasm 方面取得了巨大进展。社区从这些早期经验中学到了很多，这影响了我们创建一个新标准，我们现在称之为组件模型。组件模型处于比 WASI 更低的级别，它与 WASI 一起工作良好但不依赖于 WASI。这是我们设想的软件生态系统的结果，该生态系统不仅基于便携式计算单元，而且还具有可组合、可互操作和平台可虚拟化的 WebAssembly 模块。

让我们分解一下：

• 可组合性：允许以独立于语言的方式重用模块化代码。

• 平台虚拟化：将组件在给定环境中运行所需的平台特定部分分层的能力。早期针对平台虚拟化和可组合性功能的提议称为模块链接。

• 互操作性：对于可组合和可虚拟化的组件，我们需要一种在组件之间交换信息的方法。我们从一个称为接口类型的提案开始，但这现在也是组件模型提案的一个关键特性。

  
  

这是组件模型如何开始形成的故事。之前的每一个提案现在都被提炼成这个总体标准。我们希望在今年晚些时候看到 WASI 标准和组件模型的下一个主要稳定迭代。

WASI 标准 - 我们现在在哪里？

下面，我们将带您了解 Wasm、WASI 和组件模型的发展历史。

2019 年：纯编译目标，添加将系统调用连接到主机的早期接口。在许多方面，我们似乎正朝着 POSIX 的 WebAssembly 版本前进。我们能够编写一个非常简单的 CLI，并在桌面或无服务器功能中使用 Wasmtime 运行它。

2020 年：WASI API 专注于任何 CLI 程序可能需要的各种东西，例如系统时钟或文件系统。 Fastly 的 Lucet Wasm 运行时与 Wasmtime（一个 BA 项目）合并。

2021 年：当然，所有这些元素都将继续发展和改进。 2021 年，我们开始看到特定于用例的新 WASI 接口的开发，例如用于推理需要硬件加速的wasi-nn 。这也是Luke Wagner开始定义组件模型的一年。

2022 年：我们开始看到新的更高级别的 API，用于使 Wasm 模块在需要使用键值存储或发布/订阅消息服务等功能的云环境中运行良好。终于，经过一番努力，WASI sockets 被引入。 2023 年：我们正在努力实现组件模型和 WASI 标准的稳定性里程碑。

回顾 2019 年的历程，您可以开始看到随着用例的激增以及用户开始挑选他们需要和不需要的东西，标准是如何多样化的。从一个无处不在的块到一组不断增长的更小的构建块，这些构建块旨在在一个灵活的框架内相互操作：组件模型。

什么是组件模型？

在这个模型中，开发人员可以挑选他们的应用程序的各个部分，以不同的语言实现，作为不同的价值主张。随着开发人员开始创建 Wasm 组件库，其他开发人员可以将它们视为世界上最大的“乐高积木”箱。

在一个完整的循环时刻，我们相信当组件模型开始影响我们编写 Web 应用程序的方式时，新的创新将会到来。考虑到网络是那些很酷但受限的环境之一，用户非常不耐烦——这是新实验的温床，这是有道理的。

例如，我希望组件能够使为 Web 应用程序设计语言中立的插件系统变得更加容易。如果像 Python 这样的语言运行时需要一个片段，那么利用该语言运行时的多个组件都可以使用它。将此与当今世界进行比较，我们只有 Wasm 模块（没有组件），并且这些模块通常是在将所有编译时依赖项烘焙到一个二进制文件中的情况下构建的。如果一个大型应用程序要支持第三方插件，那么很可能每个 Wasm 插件都会有重复的依赖项，从而导致大小和内存膨胀以及下载速度变慢。

有了未来的 Web Wasm 组件系统，单个应用程序可以选择用任何语言编写的组件，应用程序只需要准确下载它需要的东西，并像任何其他带有导入的 ES 模块一样与组件交互。在这个世界上，最好的组件将升至最高点。最好可能意味着最快或最干净的 API，但最重要的是它的定义特征不会是源语言。祝最好的组件获胜！

为 WASI 和组件建立稳定的技术基础

使 WASI 标准和组件模型成为现实的很大一部分是 BA 在创建可用技术框架方面所扮演的角色：SDK、工具和核心组件；所有这些都以一致且安全的方式构建，并且作为最佳实践的示例可供所有人访问。

同样，BA 技术指导委员会 (TSC) 的作用对于为每个 BA 项目提供技术治理和支持至关重要。我们与 W3C WebAssembly 和 WASI 工作组中设计最佳标准集的人们一起工作，这意味着我们与他们合作以确保一切都在实践中发挥作用。 W3C WebAssembly 和 WASI 小组专注于这些标准的最终确定，而 BA 则专注于让它们尽快在社区内使用，以建立一个积极的反馈循环。

BA 章程的另一个重要部分是实现语言和环境的互操作性。 BA 提供了为许多不同语言生成语言绑定的工具，但如何实现语言互操作性的一个方面是我们需要各种语言生态系统中的注册表和包管理器来与 Wasm 组件互操作。这就是为什么我们致力于设计一个注册表协议（称为 warg）作为SIG-Registries的一部分，它使任何实现该协议的注册表都能够发布、使用、存储和共享 Wasm 组件。

也许任何 Wasm 软件堆栈中最关键的部分是 Wasm 运行时，而 BA 托管两个！ Wasmtime 是用 Rust 编写的，通常是试验新 WASI 和 WebAssembly 提案的试验台。 WebAssembly Micro-Runtime ( WAMR ) 是用 C 编写的，支持许多架构，包括像 ESP32 这样的微型架构。这两个运行时都是 Wasm 运行时的重要参考实现。用于构建 Wasm 模块的 SDK 和工具符合 Wasm 标准，因此任何符合标准的 Wasm 运行时（包括那些不由 BA 托管的）都可以在这些软件基础上构建。

考虑到通过 WASI 和组件模型以及字节码联盟的实现发展的所有令人兴奋的新标准，我预计 2023 年将是激动人心的一年！

立即免费开始使用 Cosmonic：立即启动！

通过贝利海耶斯 |字节码联盟 TSC 和 Cosmonic 总监