关于 WebAssembly（通常简称为 Wasm）及其在云计算领域的未来。 对于那些只了解 Wasm 最初形式（浏览器技术）或第二个主要用例（游戏技术）的人来说，这可能会让他们感到惊讶。 这两种用途都在蓬勃发展，但还有第三种用途，即作为服务器技术。
WebAssembly 最初被设计用来做很多事情，其中最引人注目的是“在浏览器中正确地执行 Javascript”，但它日益流行的一个关键原因是作为一个跨平台的抽象层。 当开发人员编写一些代码并将其编译为 WebAssembly（您可以使用许多不同的编程语言来完成）时，它将在任何具有运行时支持的平台上运行——无需任何更改。 这最初意味着您可以保证多个芯片组上的多个操作系统上的多个浏览器之间的二进制兼容性，但随着 WebAssembly 的成熟，它有了一个新模型：WASI，或 WebAssemby 系统接口。
WASI 由开源基金会字节码联盟支持，是“无头”的，这意味着 WebAssembly 的基于服务器的非 GUI 版本被采纳为 W3C 标准。 它允许您在运行不同芯片组的不同操作系统上运行服务器应用程序。 因此，同样的 Wasm 可执行文件将在具有 TSMC 芯片组的 Macintosh M2、具有 AMD 硬件的 Linux 发行版、具有 Intel CPU 的 Windows 机器或基于 Arm 的 Raspberry Pi 上运行——同样，无需更改。 在 Profian，我们对其进行了扩展，允许您在可信执行环境中运行 Wasm 应用程序，支持 Intel SGX 和 AMD SEV-SNP 平台上的机密计算——所有这些都使用相同的可执行文件。
使用 Kubernetes 运行 WebAssembly 工作负载
这与 Kubernetes 有什么关系？
好吧，Kubernetes 允许您在 Linux 容器中运行各种平台（主要是基于 Linux 的）上的应用程序。 Linux 容器（过去称为 Docker 容器，现在倾向于简称为容器）允许您在符合 OCI（开放容器倡议）标准的运行时运行可执行代码。 在这个程度上，WebAssembly 有点类似于容器，因为每个容器都允许运行时执行标准化的可执行格式。 您可以编写相同的微服务在容器中运行，或者将其编写为作为 WebAssembly 可执行文件运行。 然而，这就是一些主要差异出现的地方。容器基本上是 Linux 操作系统的抽象，而 WebAssembly 提供了一个非常不同的目标层——它基本上是一个虚拟机，在所有平台上提供标准化的 CPU。 这意味着您需要采取的方法来使您的微服务作为容器可用，这与 WebAssembly 的方法非常不同（尽管自动化正在出现，应该允许在开发过程的后期做出选择而不需要太多努力） . 另一个区别是，运行 WebAssembly 可执行文件所需的依赖项数量（运行时和语言依赖项占几十兆字节）通常比容器（典型的依赖项集将达到数百兆字节）小得多 或者更多）。 WebAssembly 运行时可以针对性能和 JIT 编译进行优化，而这些方式对于容器来说通常更难或无法实现。 WebAssembly 还提供了围绕隔离和功能授予的安全保证，而容器很难支持这些。
Kubernetes 在哪里出现？ Kubernetes 的作用是允许您跨多个分布式系统编排和部署容器，这些系统提供适当的运行时环境。 它真的很擅长这一点，虽然设置和运行起来可能很复杂，但它提供了一种在一个或多个云上跨多个系统部署和管理分布式应用程序的好方法。 事实上，容器已经变得如此流行，以至于现在可以使用 Kubernetes 来部署其他类型的工作负载，包括虚拟机和无服务器应用程序。 当然，鉴于 WebAssembly 的流行程度，人们也开始支持使用 Kubernetes 部署 Wasm 工作负载。 Wasm 工作负载是否非常适合 Kubernetes 是有争议的，但您可以对虚拟机和无服务器应用程序说同样的话，而 Kubernetes 如今用途广泛，而且对于本文而言重要的是，不存在等效的编排平台 对于 Wasm。
服务器上的 WebAssembly 是计算的未来
对部署和运行 WebAssembly 工作负载感兴趣的人们正在考虑使用 Kubernetes 来实现这一点。 但为什么首先要使用容器呢？ Docker 的最初发明者之一所罗门·海克斯 (Solomon Hykes) 在 2019 年发推文说：“如果 WASM+WASI 在 2008 年就存在，我们就不需要创建Docker。 这就是它的重要性。 服务器上的 WebAssembly 是计算的未来。 标准化的系统界面是缺失的一环。 希望 WASI 能够胜任这项任务！”
但 WebAssembly 远不及容器成熟，而且肯定还无法与围绕容器及其部署发展起来的令人惊叹的生态系统相提并论——包括 Kubernetes 社区和 CNCF（云原生计算基金会）。
容器似乎会存在一段时间，而 Kubernetes 将继续蓬勃发展以允许人们部署容器工作负载。 然而，在可预见的未来，我们可以期待看到 WebAssembly 的增长有增无减，并且 Kubernetes 被用于部署这两种类型的工作负载以及其他工作负载。
因此，虽然 WebAssembly 可能会在中期取代容器，但尚不清楚 Kubernetes 是否也可以这样说。