WebAssembly 3.0 发布，64 位内存、垃圾回收全都有，先别激动，组件模型还没做完！

作者 | B. Cameron Gain

译者 | 田橙

Wasm 3.0 的发布意义重大，但那项备受期待的组件模型依然未能完成。换句话说，WebAssembly 仍未迎来那个足以改变云计算格局的“Docker 时刻”。

我所说的“Docker 时刻”，源自 Solomon Hykes 的那条著名推文。他是 Docker 的联合创始人。简而言之，他的意思是：如果 WASM 和 WASI 在 2008 年就已经成熟可用，那么 Docker 可能根本就不会被创造出来。

要是 2008 年就有 WASM+WASI 这种组合，Docker 可能根本都不会被发明出来，可想而知它有多重要。WebAssembly 在服务器端的潜力巨大——那才是真正的计算未来。当年的关键缺口，就是一个统一标准的系统接口。希望这次 WASI 能撑起这份期待。 —— Solomon Hykes (@solomonstre), 2019 年 3 月 27 日

这意味着，WebAssembly 的“伟大承诺”仍在实现过程中。而我所说的“Docker 时刻”，也就是让 WebAssembly 真正像 Docker 一样改变软件分发方式，关键在于组件模型的落地。而这个模型的完成，又依赖于 Wasi 0.3 的正式发布（稍后会详细介绍）。

不过，它的延期并不像表面看起来那样糟糕。事实上，过去一年，服务器端的 WebAssembly 生态发生了不少有趣的进展。

前 Bitnami 联合创始人、Wasm 工具提供商 Endor CEO Daniel Lopez Ridruejo 在接受采访时表示：“Wasm 的美妙之处在于，它已被业界广泛采用。Wasm 3.0 的特性将改善所有人的使用体验，而不仅限于浏览器端开发者。组件模型规范是在现有 Wasm 基础上进一步完善和扩展的，尽管进度比预期慢，但正在稳步推进。”

更少“垃圾”，更大空间

根据官方文档，Wasm 3.0 的一些核心特性，其中部分研发已长达八年，包括：

64 位地址空间

Wasm 现在支持使用 i64 作为地址类型（此前仅支持 i32），这意味着地址空间理论上可从 4GB 扩展到高达 16EB（约等于百万亿 GB）。在浏览器端（Wasm 最初设计的主要场景）内存仍被限制在 16GB，但在服务器端，这种扩展潜力无疑相当惊人。

多内存支持

文档指出，“与普遍看法相反”，Wasm 其实一直支持多内存对象，也就是多个地址空间并行使用。区别在于，过去这些内存必须在独立模块中分别声明与访问。Wasm 3.0 允许单个模块直接声明、导入并访问多块内存，甚至可在它们之间直接复制数据。这让“一次部署、处处运行”的理念更接近现实。

垃圾回收（GC）

Wasm GC 模块在轻量、低延迟的基础上，变得更加灵活，允许编译器自由选择适合的语言值表示方式（如方法表实现等）。Wasm 本身没有内置对象系统、闭包等高级语言特性，这是为了避免对某种编程语言的偏向。它做的事情很简单：只提供搭建这些特性的基础“积木”，重点放在内存管理上，而不是替语言设计更高层的抽象。

如今，Wasm 的应用早已深入各类服务与平台。无论是 Azure 的 Hyperlight、Spin 还是 wasmCloud，用户在享受这些平台功能时，往往已经在使用 WebAssembly 而不自知。

虽然组件模型尚未正式完成，但许多“类组件”能力已经通过平台如 StackBlitz、endor.dev 等得以实现和利用。

以 Endor 为例，它让 WebAssembly 的功能变得既实用又有趣。借助 WebAssembly 的极速性能，开发者可以在几秒钟内创建可复现、隔离的测试环境，而不再需要耗上几个小时甚至几天。Endor 还支持运行智能代理（agents）和 “vibe coding” 模式，帮助开发者快速、安全地验证代码。据 Endor 团队介绍，这些功能既能在浏览器中使用，也能直接通过命令行运行。

我自己试了一下：连上 Endor 服务器、装好 shell 之后，只用了几分钟，就跑出了一个“极客版”的《星球大战》第一部。

组件模型的“传说”

Wasm 3.0 并未最终纳入组件模型。虽然像 Endor 这样的平台已经非常接近，但那个类似 Docker 的神奇时刻，也就是“只需把任意应用打包成 Wasm 模块，就能在任何地方运行和部署”的愿景，依然还没有真正实现。

一旦标准化完成，开发者将能使用任意编程语言编写应用，通过 Wasm 模块同时（且异步地）在不同端点部署。组件模型的成熟，将让 WebAssembly 的适用范围超越浏览器和服务器，支持在数千个节点上同时运行多个轻量模块，实现高速分发。

这其中的关键在于组件模型的标准化，以及它与 WASI（WebAssembly System Interface）的衔接。WASI 是连接 WebAssembly 模块与外部组件的标准接口或 API。它将支持构建所谓的 WebAssembly “Worlds”，由兼容的 Wasm 组件构成的互联基础设施，有点像 Kubernetes，但不依赖容器。

2024 年发布的 WASI Preview 2 已在标准化上迈出重要一步，但尚未完全到位。预计 2025 年也难以迎来“圣杯时刻”，但或许会有令人惊喜的进展。有传言称，Wasi 0.3 可能仍无法在今年最终定稿，这意味着 Wasi 1.0 及组件模型的正式实现都将推迟。

不过，WebAssembly 的全球基础设施集成仍在持续推进，并不以 Wasi 3.0 的发布为前提。

Fermyon 联合创始人兼 CEO Matt Butcher 在采访中表示：“组件部分已经完全归入 WASI，因此还没有纳入主标准。我同意，那个关键的 Docker 时刻尚未到来，但我们确实在一步步接近它。”

https://thenewstack.io/wasm-3-0-no-component-model-and-no-docker-moment/

声明：本文为 InfoQ 翻译，未经许可禁止转载。