WASI Preview 2 让 WebAssembly 满足生产就绪要求

本文转载自 The New Stack。

WebAssembly（简称 Wasm）长期以来一直致力于革新应用开发方式。其愿景简单远大（想必大家也都熟悉），即“一次编写，随处运行”。Wasm 还承诺以近乎原生的速度运行代码。更赞的是，不同于 Java applet 等以往的通用运行时尝试，Wasm 具有默认拒绝特性，提供了更强大的安全保障和可靠的默认安全防护 — 除非开发人员另有说明，否则禁止访问系统资源。

但截至目前，Wasm 并未达到预期。虽然 Wasm 拥有巨大的潜力和庞大的社区，但缺乏必要的工具、稳定的接口和 API，因此无法真正做到生产就绪。想要使用 Wasm 的开发人员必须自己先成为一名 Wasm 专家。或者，他们也可以求助于 Wasm 平台即服务专业公司，例如 Cosmonic 或 Fermyon，这些公司可通过显著降低初始复杂性，帮助您更顺畅地上手。

不只是预览：稳定组件模型

现在就让我们来了解一下 WASI Preview 2。虽然它只被称为“Preview（预览版）”，但事实并非如此。WASI Preview 2 恰好能填补 Wasm 所需的缺失一环，使其成为可行的生产用例。WASI（WebAssembly System Interface 的缩写）是一套标准，定义了 Wasm 模块与系统资源之间安全交互的标准化方式。Preview 2 代表了 Wasm 发展过程中的一个重要里程碑，因为开发人员可以放心地在其基础之上进行开发，确信整个平台不会发生变化。

WASI Preview 2 的核心是 WebAssembly 组件模型，支持将 Wasm 组件组合成更大的组件，即使这些组件是使用不同语言编写而成。这大大提升了灵活性和跨语言兼容性。该组件模型定义了一个 Canonical ABI（应用二进制接口），它规范了组件之间的通信方式，并防止某个组件访问其他组件的内存，从而消除了最常见的错误和安全漏洞。

WASI Preview 2 的另一大特性是稳定的 API。这确保了 Wasm 应用未来的向后兼容性，可让开发人员放心地在 Preview 2 的基础上进行开发，而不必担心未来变更。它类似于 POSIX（可移植操作系统接口）为类 Unix 操作系统实现接口的标准化，有助于更轻松地编写可移植软件。

不止于“支持 Wasm 的 POSIX”

WASI 还将进一步发展，包括为各种不一定是系统资源的元素提供接口。（我们的一些社区成员正尝试将 “WASI” 更改为 “WebAssembly Standard Interfaces” 的缩写，以体现这一点）。WASI 将 HTTP 作为一级接口，这是 POSIX 所没有的一项关键网络和连接功能，它提供了更好的方法来监控模块可执行的操作，而不是将模块作为原始套接字处理（当然，您也可以这么做）。与 POSIX 相比，WASI 还简化了某些对 WebAssembly 更有意义的方面，例如将 system clocks 从 4 个减至 2 个。得益于这些改进，WASI Preview 2 成为了一个更现代化的可移植接口，适用于 Web 和后端应用。

WASI Preview 2 具有重大现实意义。以前，开发人员很难在专门的 PaaS 系统之外构建 Wasm 应用。由于 Wasm 缺乏稳定的 API 和工具，因此人们没有信心将其用作生产级技术。Preview 2 改变了这一切，为 Wasm 的广泛采用乃至成为主流技术铺平了道路。

这意味着什么呢？在构建 Wasm 应用时，您现在可以从任何语言生态系统中挑选库，将其编译成组件，然后再将它们组合成一个应用。企业内的所有团队均可使用其首选技术堆栈来开发各自负责的系统。然后，借助功能强大的组件模型，开发人员和团队可以将它们组合成一个单体应用，同时确信所有组件能够相互契合，并以可预测的方式运行。

毫无疑问，Wasm 技术蕴含巨大潜力。但目前，由于在工具、稳定性和关键功能方面的欠缺，这种潜力未能充分发挥出来。WASI Preview 2 很好地弥补了这些欠缺，为 Wasm 实现其在生产环境中的开发人员易用性扫清了道路。WASI Preview 2 和组件模型应能够大幅推动 Wasm 的采用和部署。最重要的是，它代表着一大显著进步，可让开发人员或技术领导者对 Wasm 的未来充满期待，并推动他们着手构建 Wasm 应用。

每次重大技术变革都有一个推动技术快速普及的拐点，WASI Preview 2 应该就是 Wasm 的这个拐点，它将支持世界各地的开发人员更轻松、更快速、更安全地开发软件。