后Kubernetes时代的未来？Wasmer 3.0 发布，可在浏览器外运行 WebAssembly

11 月 23 日，Wasmer 3.0 正式发布。作为开源WebAssembly (Wasm) 开源运行时的最新版本，Wasmer 3.0 可以将 Wasm 编译为适用于 Windows、Linux 或 Mac 的本机可执行文件，而无需任何运行时依赖。

创始人 Syrus Akbary 表示，新版本还能够直接使用“wasmer run”运行 WAPM 包，这是一个新重建的 Rust API，并改进了对 WASI 的支持，它添加了文件 I/ O 和 WebAssembly 的其他功能，用于在浏览器外运行。

Wasmer：从任何语言到任何操作系统

WebAssembly 最初被设计为在 Web 浏览器中，以接近本机的性能，安全地运行以其他语言（例如 C/C++）编写的代码。2015 年，Luke Wagner 在自己的 Mozilla 博客上发布了一条公告：“我很高兴向大家报告，我们在 Mozilla 开始跟 Chromium、Edge 和 WebKit 的工程师们合作创建新的标准——WebAssembly。它定义了一种可移植，而且尺寸和加载效率更高的格式与执行模型，专供 Web 编译场景使用。”

随后，在 W3 的协助下，核心 Wasm 规范已经被列为“推荐”项目，且各大主流浏览器也都为其提供支持。并且多数语言都已经能够支持 Wasm。Wasm 在浏览器领域取得了成功，也拥有了 Adobe 和 Figma 等体量可观的采用者。但在此期间，Wasm 在浏览器之外的优势也被越来越多的人所注意。对于 Wasmtime、Wamr、Wasm3、WasmEdge 和 Wasmer 等采用 Wasm 格式的非浏览器运行时，其一方面展示了 Wasm 规范的灵活性，比如把 Wasm3 当成解释器来执行；另一方面则能支持 JIT 和 AOT 编译，外加各种缓存及优化功能。

虽然 Wasm 在浏览器中高度依赖于 JavaScript 和 Wasm 运行时之间的桥梁，但非营利性组织字节码联盟（Cosmonic、Fermyon 和 Suborbital 等都是其成员）一起参与研发，希望为 Wasm 引入系统绑定。Wasm 系统接口（WASI）就是典型案例，其添加了能够与文件系统、环境变量、时钟和随机数生成器等系统资源进行交互的标准化支持。

在这过程中，已经有很多人认为 Wasm 的未来就在于能在浏览器之外运行它。Fermyon 的 CEO Matt Butcher（软件工程师、前教授，以及包含 Helm 在内的数十个开源项目的创始成员） 认为，Wasm 像虚拟机和容器一样，能够在云中运行，这才是真正令人兴奋的地方。Wasm 代表了云原生技术的新时代，“我们喜欢容器。我们中的许多人多年来一直参与 Kubernetes 生态系统。但我们也很兴奋，因为在容器生态系统中有些没有解决的问题，现在我们正在找到解决方案。这就是为什么我们将其视为下一波浪潮。”

如今的新生标准已经让 Wasm 能够在浏览器之外发挥作用。很多 Wasm 项目的创建者/维护者对此感受非常积极：凭借着与浏览器高度匹配的各种特性，Wasm 在浏览器之外更有种“广阔天地、大有作为”的意味。作为多个最大开源 Wasm 项目的创建者/维护者，Matt Butcher 等人发表了一篇技术博客，从多个积极的角度讲解了为什么他们认为“Wasm 适用于浏览器，更适用于云”。

适用于浏览器，更适用于云

网络浏览器中的语言运行时必须满足几大特征，而这些特征在云端也同样非常重要。

• 安全性：如果要在浏览器中运行不受信代码，则需要确保它是独立运行的。这一点在云端也同样适用。
• 跨平台/跨架构：当我们为浏览器构建代码时，当然希望能一次编写、随处运行。这一点在云端也同样适用。
• 多语言：Wasm 项目的一大目标，就是将浏览器扩展到多种语言。云开发还不像浏览器开发那样以 JS 为中心，所以多语言支持可以说是个必要前提。
• 速度：没人愿意坐等网页加载，云端同样如此。只有实现了即时加载，才能进行快速扩展。
• 效率：浏览器在功耗方面需要控制好自己的“胃口”，云基础设施也是一样。运行时效率越高，运营成本也就越低。
• 代码大小：下载快慢，很大程度上取决于我们要下载怎样的对象。较小的二进制文件下载得快，这类对象在云端也能够更快移动。

安全性

云软件运行中的一大难题，就是了解其安全属性、攻击面和如何保障组织安全。当前供应链暴露出的安全漏洞以及未打补丁的遗留操作系统，已经给企业造成数十亿美元损失和无法估量的业务时间拖延。

而 Wasm 的一大重要目标就是提供一个简单、易于理解的表面区，确保代码能够在沙箱内执行，充分考虑到攻击者从外而内或由内而外可能采取的一切基础设施危害方法。Wasm 这种强制在沙箱内运行代码、再与沙箱外操作系统交互的办法，被具体拆分成了一个个精细的启用选项。宏观来看，我们可以在启动时，将 Wasm 字节码中所执行的每个“系统调用”都提供给运行时的一组函数处理。

如此一来，如果大家希望禁用文件系统访问、网络访问、甚至是系统时钟访问，都可以随时变更主机函数集来实现。再与具备边界检查的线性程序内存相结合，我们就得到了一个能够执行任意不受信代码的容器，其简单性与攻击面受控性都远远优于传统的虚拟机和容器安全模型。

在现实世界中，这相当于是给操作人员提供一个能够安定运行不受信代码的执行环境。我们可以在这里测试未经审核的第三方依赖项，或者用户提交的代码（例如插件和用户定义函数，简称 UDF）。对于用户可以上传软件扩展代码的情况，大家肯定不敢贸然把这些提交内容直接运行在基于容器的平台上，毕竟其中还是有很大的内部基础设施接触和损害空间。

另外，我们还要考虑到用于执行用户代码的基础容器镜像可能包含漏洞，因此当需要对数百、数千甚至更多用户提交的容器打补丁并进行操作系统重构时，这必然会造成巨大麻烦。通过从运行程序中删除大部分“类操作系统”元素，Wasm 提供了一个更可控、更易于理解的底层基础，帮助用户在此之上构建起安全的代码运行环境。

跨平台/跨架构

Wasm 最受欢迎的特性，应该就是突出的平台与架构中立性了。更重要的是，Wasm 的强大已经远远超出了 JVM 之类“一次编译、随处运行”的想象。这里我们以组件模型为例，其允许开发人员编写代码并将其 API 导出为接口。假设我们打算使用密钥库，而密钥存储的接口可能如下所示：

set: func(key: string, value: payload, ttl: option<u32>) -> expected<unit, error>

get: func(key: string) -> expected<payload, error>

delete: func(key: string) -> expected<unit, error>

如果我们想要实现一个密钥库，当然可以用任何语言来编写（示例中使用的就是 Go），而且只要导出到这个接口，就能将其编译成 Wasm 模块。之后，另一位想要使用这个实现的开发者可以用另一种不同的语言编写代码，并继续使用我们用 Go 编写的键值实现。从本质上讲，这就相当于提供了一个通用库或依赖项注册表，能够根据各个具体用例的需要组合起来。因此，大家不必为每种语言建立单独的客户端库，而是实现一次编写、随意“组合”。无论大家使用哪种语言、平台或者架构，共享和协作都将变得轻松而顺畅。

Matt Butcher 等人认为，除了 Wasm 的跨平台/架构可组合性之外，它还特别适合在后 Kubernetes 时代下作为运行时方案。“我们知道这个观点可能有点激进，但人们会很快意识到，Kubernetes 和容器技术的拓展边界已经快到头了。没错，我们总会说容器可以‘随处运行’，但扪心自问，大家都知道这个结论有待商榷。为了支持不同的平台，我们需要为每个平台+架构组合构建不同的镜像。此外，容器其实是一种 Linux 技术。没错，也有一些特别聪明的贡献者让 Windows 也获得了容器，但这已经是套完全不同的技术方案了（无法直接运行 Linux 容器，常规容器平台也没法直接运行 Windows 容器）。”

另外，容器运行时的开销并不小（特别是在 Kubernetes 的时候），所以很难在边缘位置广泛应用。最重要的一点，容器还需要不断支持越来越多的定制化处理器。可以看到，Wasm 简直堪称完美的解决方案——它具备明显的平台和架构中立性，代码体积小，代码既可以直接运行在大型云服务器上、也能在边缘位置的微型设备中起效，而且无需任何重新编译。

Matt Butcher 等人承认容器在云过渡时期带来的种种便利，但也坚持 Wasm 才代表着后 Kubernetes 时代的未来形态。

多语言支持

我们知道，Wasm 的另一大关键特性就是支持多种语言。由于 Wasm 代表一个编译目标，所以只要你使用的语言支持 Wasm 就可以了。有些语言的 Wasm 支持来得较早，有些稍微晚些，但目前大部分语言都已经开始甚至完成了这项工作。总之，开发者可以用不同的语言编写同一应用程序内的各个服务、甚至是各个部分。这就是组件模型的威力所在！

对此，Matt Butcher 等人再放豪言：“我们认为，Wasm 有可能会成为最后一种插件模型”。截至目前，为任何工具编写插件都是种痛苦的体验。大家要么必须使用相同的语言编写，要么得设置某种通信协议（例如 gRPC），要么使用某种商定的 stdin/stdout 合约输出二进制文件。这些选项局限性强、效率也不高。而使用 Wasm，插件可以用任意语言编写、再编译成 Wasm。之后，该 Wasm 模块就能作为插件模型的一部分由任何其他语言执行——无需劳烦 shell、也不必跨进程通信。最重要的是，Wasm 还有速度和大小优势。

速度

让公有云成为可能的关键支持技术，其一是虚拟机，其二是容器。二者都是在计算世界中占有一席之地的伟大技术，但却不可能是满足一切云需求的至高“银弹”。当在资源受限或者使用率极高（例如边缘计算、物联网或规模巨大的数据处理集群等场景）的条件下运行代码时，虚拟机和容器其实会阻碍我们充分发掘硬件性能的能力。

而 Wasm 在多数情况下都能提供相同或更高的隔离保障，让我们能够安心剔除虚拟机和容器的底层“公有云安全网”，更好地使用运行代码的服务器和设备。由于 Wasm 是一种低级字节码，所以可以编译并支持任何硬件架构、任何操作系统，因此我们完全能够，也应该直接在裸机上运行 Wasm。这样就能把工作负载更紧密地打包至可用硬件，并在性能、能源效率、环境影响等方面迎来新的飞跃。

这些性能优势在云功能等临时性工作负载中体现得尤其明显。由于 Wasm 运行时及其加载的代码，通常要比等效的容器镜像或虚拟机小一个数量级（甚至更多），所以可以通过更高的复制量快速实现启动和终止。在大部分云部署场景下，这些都是很重要的特性，能够更灵活地部署软件以应用流量高峰，进一步扩展来消化总流量波动。而且 Wasm 模块实际上只是个程序，绝非操作系统中的容器或虚拟机，因此主机操作系统的控制和硬件优化机制也能高效利用多核心架构，同时继续保持工作负载间的强隔离。

大小和效率

在目前的大部分用例中，我们其实都在过度消耗云资源。我们得准备充足的副本来满足峰值负载要求，而这些副本在大多数时间里都处于闲置状态，平白浪费资源。同样的，由于我们需要针对超高需求进行优化，所以也得分配比必要水平更多的 CPU、内存和存储空间，以便随时应对流量高峰。承担这么多浪费的理由只有一个：目前的解决方案无法实现快速扩展。

Wasm 的大小和效率优势，让快速扩展成为了可能。我们几乎可以立即扩大规模，再轻松缩减回正常水平。我们可以在整个数据中心或集群内安装同样的小规模 Wasm 模块，并在需求出现之前不实际执行。这样，我们就能省下副本资源，保证只在必要时才把宝贵的资源拿出来。

而有了 JIT/AOT 运行时，我们还能对 Wasm 二进制文件进行执行预优化，进一步减少电力和资源消耗。

在多数场景下，需要处理的系统库和文件工件数量也显著减少，因此我们实际处理的对象大小要比容器时代小得多。

总而言之，所有这一切都指向了 Wasm 在云端的核心优势：比其他云服务更低的运行成本。虽然 Wasm 还很年轻、还需要完善，但它提供的种种可能性已经非常有吸引力，如果社区发展更为壮大，Wasm 最终会发展出更美好的未来图景。

参考链接：

https://wasmer.io/posts/announcing-wasmer-3.0

https://devclass.com/2022/11/25/wasmer-3-0-released/

https://wasmer.io/posts/wasm-as-universal-binary-format-part-1-native-executables

https://thenewstack.io/whats-next-in-webassembly/

https://www.wasm.builders/thomastaylor312/why-webassembly-belongs-outside-the-browser-331a