为什么学习WASM：快速上手

在 KubeCon NA 2024 之后，许多人对这个变得非常好奇，这绝对有充分的理由。从工程的角度来看，在性能、跨平台能力和整体安全性方面都带来了大量的好处。

在本快速入门指南中，你将了解使用WASM的几个关键原因，以及它如何为你带来好处。

WASM 代表 Web Assembly，自 2017 年起一直存在。最初，WebAssembly 的目标是让工程师能够使用除 JavaScript 以外的编程语言开发网络应用。这在很多方面都很有道理，主要原因有两个：

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容器要小得多（高达80%，因为它们自动部署为类似于空白的镜像），因此启动速度更快。
• 训练机器学习模型似乎比使用容器快了2倍，同时内存使用减少了90%。

不过，有个问题。现在的WASM还不支持多线程，因此并发就成了一个问题。因为这个原因，不仅并发的应用程序会遇到问题（也许可以通过Goroutines处理），而且延迟也可能是个问题。

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

一旦构建完成，默认使用类似Scratch的容器镜像，体积非常小。体积小且使用精简的Scratch镜像，安全性大幅提升。因为Scratch使用极少量的操作系统组件，几乎不可能有漏洞存在。

从纯粹的WASM视角来看，它是内存安全的，并且默认情况下被隔离运行。它被设计为在这种模式下运行，因此无法与运行它的操作系统进行交互。例如，如果你在Ubuntu系统上运行一个WASM/WASI应用程序，它不能与Ubuntu内核进行交互，除非你通过运行时指定权限。

你可以用你想用的任何你喜欢的语言编写，WASM 会以同样的方式编译它。

例如——你可以用 Python 编写应用栈的一部分，我可以用 Go 编写另一部分。

这在服务器端和网页上都是一样的。

这是一个非常棒的事情，因为它能让工程师更舒适地紧密合作。

看到这个时，我想到当你用 Go 构建二进制文件的时候。无论你当前使用的是什么架构，你都可以用 Go 代码构建二进制文件。如果你在 Windows 上有 Go 代码，运行 go build 命令会生成一个 .exe 文件。如果你在 Mac 上有 Go 代码，运行 go build 命令会生成一个 .pkg 文件。

你可以将WASM用于浏览器上的应用或服务器端的应用。WASM于2017年诞生，最初是为浏览器设计的，但在2019年，WASI则是在2019年创制，以作服务器端环境使用。因此，你可以在诸如虚拟机或Kubernetes这样的平台上运行WASM应用。

WASM完全独立于底层硬件，而WASI则负责确定它在何处以及如何运行。这就是为什么你可以在x64上编译一个WASM应用程序，并在ARM上运行它。

有意思的是，Kubernetes的创始人表示，如果在2008年就有了WASM和WASI，可能就没有了容器化技术。