为什么选择 WASM：快速入门

KubeCon NA 2024 之后，很多人都开始对此感到好奇，这也不无道理。从工程角度来看，它在性能、跨平台能力和整体安全性方面都具有巨大的优势。

在本快速入门指南中，您将了解使用 WASM 的一些关键原因以及它能给您带来哪些好处。

WASM是什么？

WASM 代表 WebAssembly，它自 2017 年以来就已存在。WebAssembly 的最初理念是让工程师能够使用 JavaScript 以外的编程语言创建基于 Web 的应用程序。这有很多好处，但主要有两点：

1. 您可以获得其他语言的优势（例如，在许多情况下，Go 的性能比 JavaScript 更高）。
2. 任何人都可以使用自己最熟悉的语言来构建同一个应用程序，因为它会经过 WASM 编译器。

速度、性能和可扩展性固然重要，但第二点才是真正突出的。假设你有三位开发人员：一位使用 Python，一位使用 Go，还有一位使用 Rust。他们可以继续使用自己选择的语言，因为最终所有代码都要经过 WASM 编译器。

在接下来的五个章节中，您将看到 WASM 的一些关键区别。

兼容性

它可以在任何地方运行，也可以在任何地方编译。例如，你可以在 x64 机器上编译，然后在 ARM 机器上运行。在二进制文件本地构建，且一些机器运行 Intel 或 AMD CPU，而另一些机器运行基于 ARM 的 CPU 的时代，这意义重大。

这可以称为指令集架构（ISA）。

由于 WASM 编译器与各种语言（稍后会详细介绍）和架构的交互方式，其目标是实现代码构建位置的独立性。这使得工程师和开发人员几乎可以在任何地方构建代码，并且无论代码位于何处，应用程序堆栈都能按预期运行。

速度

从速度角度来看一些统计数据：

• 从冷启动开始，运行 WASM 工作负载的速度比容器快 160%。
• WASM 的速度比容器化应用程序快 10-50%。
• WASM 容器体积小得多（由于它们使用类似 scratch 的镜像自动部署，体积可缩小 80% 以上），因此启动速度要快得多。
• 训练机器学习模型的速度似乎提高了 2 倍，而内存使用量却减少了 10 倍。

然而，这里有个问题。就目前的 WASM 而言，它不支持多线程，因此并发性是个问题。正因如此，不仅并发应用程序会遇到问题（或许 Goroutine 可以解决这个问题），延迟也可能成为问题。

安全

默认情况下，WASM 不会像容器或 Pod 那样与任何底层操作系统组件进行交互。

它默认使用类似 Scratch 的容器镜像进行构建，因此体积非常小巧。更小的体积加上像 Scratch 这样精简的镜像，安全性自然会更高。这是因为像 Scratch 这样的镜像只使用了极少的操作系统组件，所以极难出现漏洞。

从纯粹的 WASM 角度来看，它默认是内存安全的，并且运行在沙盒环境中。它的设计初衷就是如此，因此它无法与运行它的操作系统进行交互。例如，如果你在 Ubuntu 系统上运行一个 WASM/WASI 应用程序，除非你通过运行时环境进行指定，否则它无法与 Ubuntu 内核进行交互。

跨平台

你可以用任意多种不同的语言编写代码，WASM 都会以相同的方式编译它们。

例如，你可以用 Python 编写你的应用程序栈部分，而我可以用 Go 编写我的应用程序栈部分。

服务器端和 Web 端都是这样工作的。

这是一件非常好的事情，因为它让工程师们能够以他们感到舒适的方式更紧密地合作。

我第一次看到这个的时候，就想到了用 Go 语言构建二进制文件的过程。只要你有 Go 代码，无论它当前运行在什么架构上，你都可以构建它。如果你的 Go 代码在 Windows 系统上，它会构建一个.exe二进制文件。如果你的 Go 代码在 Mac 系统上，.pkg运行go build命令后它也会构建一个二进制文件。

跨源

WASM 可用于浏览器应用或服务器端应用。WASM 创建于 2017 年，最初是基于浏览器的，但 2019 年，WASI 被创建出来，用于在 Web 之外的服务器端运行时环境运行。这就是为什么您可以在虚拟机甚至 Kubernetes 上运行 WASM 应用的原因。

WASM 完全独立于底层硬件，WASI 会负责决定它应该如何以及在何处运行。这就是为什么你可以将基于 WASM 的应用程序编译到例如 x64 架构上，然后在 ARM 架构上运行它。

具有讽刺意味的是，Kubernetes 的创始人曾表示，如果 WASM 和 WASI 在 2008 年就已经存在，容器技术就不会存在。