我是一个技术爱好者，我一直在寻找下一个事物——下一个改变游戏规则的技术。 问题是……改变游戏规则的技术很少见，例如： 虚拟化、云计算和容器。

幸运的是，我们即将体验另一个规则改变者的乐趣，它叫做 WebAssembly！ 或者它被称为 Wasm。

在这里不展开说明虚拟机或者容器化技术，但我们已经经历了云计算的前两波浪潮，并且即将经历第三波浪潮。

第一波浪潮是建立在虚拟机上的。 它们很棒，我们今天仍在使用它们。 但创新永不停息，不久之后第二波浪潮就到来了。

第二波云计算是建立在容器之上的。 除此之外，它们比虚拟机更小、更快、更轻。 不过，创新永不停息，不久之后第三次浪潮就到来了。

云计算的第三次浪潮已经到来，它是建立在 WebAssembly 之上的。 正如您所料，WebAssembly 比容器更小、更快、更轻量。 它也更安全、更便携，但我们将在以后的文章中介绍这一点。

所以，图片看起来像这样。

在接下来的几年里，我希望这三项技术能够一起工作。 容器将继续成为一个增长领域，并成为大多数人的首选解决方案，虚拟机和 WebAssembly 将用于特定用例。

然而，随着工具和生态系统的成熟，预计 WebAssembly 会变得越来越占主导地位——就像容器慢慢接管许多虚拟机用例一样。

当开始使用 WebAssembly 时，您很快就会注意到我们在 WebAssembly 和 Wasm 之间来回切换。

至少现在，在浏览器中引用它时我会尝试使用 WebAssembly，在云或服务器上引用它时我会尝试使用 Wasm。

“云原生 WebAssembly”正在云中使用 WebAssembly 来实现云应用程序和云用例。 有时你会听到它被称为云端 WebAssembly、服务器端 WebAssembly 或服务器上的 WebAssembly。

随着大量公司的不断研发，现在我们已经拥有了第一波云端 Wasm 运行时和工具。 我们只需要编写应用程序并使用工具来运行它们。

您可以满足常规的云应用程序要求，并使用您最喜欢的语言（例如 C、C++、Rust、Go 等）对其进行编码。

第一个区别出现在编译时。 您无需编译为 linux/arm64 等操作系统和架构，而是编译为 WebAssembly (wasm32/wasi)。 这是因为 Wasm 是它自己的字节码格式。

然而，Wasm 字节码需要运行时来执行。 没关系，存在大量 Wasm 运行时，您几乎可以找到一个满足任何需求。 一些流行的云示例包括：

存在许多其他 Wasm 运行时，但重点是，运行时将 Wasm 字节码转换为云服务器的本机机器。

下图显示了在各种云和边缘平台上执行的单个 Wasm 二进制文件。

如果不提及 Kubernetes，云原生的应用就不完整。

社区中的主要参与者，包括 Microsoft、WasmEdge 和 Docker，一直在将 runwasi 作为容器填充程序方面做出了出色的工作。 这项工作允许 containerd 与 Wasm 运行时一起使用并控制 Wasm 应用程序的生命周期。

由于 Containerd 是 Kubernetes 使用的最流行的运行时，这项工作为 Kubernetes 以最少的努力来调度和管理 Wasm 应用程序打开了大门。

举一个很好的例子，Azure AKS 已经允许您创建运行 runwasi containerd shim 的 Wasm 节点池。 您将它们定义为 RuntimeClass，Kubernetes 可以为它们调度 Wasm 工作负载。

已经尝试了将 Wasm 引入 Kubernetes 的其他方法（Krustlet）。 然而，runwasi 和 shim 方法似乎是最有可能的前进方向，我们应该很快就会在 Kubernetes 上看到 Wasm 应用程序。

WebAssembly (Wasm) 是一项久经考验的技术，它使网络变得更快、更安全且极其便携。

“云原生WebAssembly”是在服务器和云端使用Wasm，并使用Kubernetes等编排工具来部署和管理Wasm应用程序。

推动 Wasm 进入云原生生态系统的主要力量是 Wasm 应用程序比容器更小、更快、更安全、更便携！

您可以像平常一样编写应用程序，将它们编译为 Wasm 二进制文件，并在具有 Wasm 运行时的任何架构和操作系统上执行它们。

云原生 Wasm 还处于早期阶段。 然而，未来是光明的，现在正是参与其中的好时机。