导读：我们知道 Wasm 在浏览器中运行良好，百现在是时候对 Wasm 在服务器端的可能性感到兴奋了。
图片来源：CC BY 3.0 Mapbox ERG
基于浏览器的WebAssembly (Wasm) 作为后端技术越来越受关注，开发者正在从“嗯，这听起来很有趣”转向“让我们看看 Wasm 除了浏览器、视频游戏和内容流之外还能做什么”。
与此同时，Wasm 本身也开始发生变化和转变。所有这些都使得现在是重新审视 WebAssembly 技术的好时机。
当开发者评估 Wasm 的全新用途时，应该关注以下五件事情：
1 界面
Wasm 最初是为浏览器设计的，没有系统界面来提高其整体安全性。最初以 Web 为中心的 Wasm 的作者不希望应用程序能够请求资源，就像 Java 小程序（Applet）被限制在浏览器中一样。
但使用 Wasm 的后端开发人员需要一个接口，以便可以移植和使用现有的程序和编程范例（例如 Python、Ruby、Web 服务器等）。输入WebAssembly 系统接口扩展（又名 WASI），这是一组类似 POSIX 的 API，提供文件系统、网络和加密等操作系统风格的功能。WASI 改进了现有软件以及使用常见的现有范例（使用文件、端口等）编写的新程序的执行和可移植性。
那些认为 Wasm 应该保持纯粹的人，还有和那些想要类似 POSIX 的系统接口的人之间存在着很大的推力。后端服务器的一些人提出了一种折衷方案，建议那些想要按照最初的意图使用 Wasm 的人应该这样做，但可以为那些想要它的人添加该接口。而我认为WASI对于服务器端的成功也是必要的。
2 表现
在一些基准测试中，Wasm 表现出了令人印象深刻的性能。毫无疑问，Wasm 运行快速高效，但开发者应该对基准数据仍持保留态度。
例如，在最近的Vercel 基准测试中，Wasm 表现非常出色。在计算密集型评估的电子数字部分，Wasm 比 Java 快得多。但使用用 C 编写的本机 Rust 编译器在裸机上运行，速度仍然是 Wasm 的4倍左右。
此外，在其它一些 Vercel 子测试中，Java 比 Wasm 的速度要快得多。
诚然，应用程序的完整性能将取决于许多不同基准的一些结果，但值得注意的是，Wasm 并不是一个灌篮高手。如果将更多元素（例如 WASI）置于 Wasm 之上，则尤其如此。
另外，请开发者继续关注垃圾收集以及它可能如何影响性能。
3 安全
如前所述，出于系统安全原因，Wasm 的范围受到限制。
通过减少安全限制（例如添加 WASI 接口时），则会增加攻击面。Wasm 可能越受欢迎，添加的内容就越多，这将导致更多的人为错误或恶意行为发生。多租户应用尤其是一个值得关注的领域。
Wasm 比容器会更安全吗？比虚拟机还少吗？Wasm 是否在两者之间创造了一个甜蜜的安全角落？保持功能和安全性之间的平衡对于未来至关重要。考虑扩大 Wasm 使用范围的开发者需要关注这场辩论的焦点。
4 可移植性
Wasm 最大的吸引力之一是它的跨平台可移植性。
Wasm 是一种中性的二进制格式，可以放入容器中，并在任何地方运行——这是我们日益多语言化的硬软件世界的关键之处。
开发人员不喜欢为多种不同系统编译软件，因为每个额外的架构（x86、Arm、Z、Power 等）都会增加自己的测试矩阵，它是一个非常昂贵的问题，最后 QE 是很多开发团队的瓶颈。
借助 Wasm来编写应用程序，编译一次，测试一次，然后将它们部署到跨越混合云（从边缘到数据中心再到公共云）的任意数量的硬件和软件平台上。Mac 上的开发人员可以将程序编译为 Wasm 二进制文件，在本地进行测试，然后可以自信地将其推送到要部署的所有不同机器上。
所有这些机器都已经安装了 Wasm 运行时，该运行时会针对特定平台进行底层测试，从而使 Wasm 二进制文件非常可移植，就像 Java 一样。
当开发者将程序编译为 Wasm 二进制文件时，你可以将其发送到容器的注册表，将其拉到另一台具有 Wasm 运行时的机器上，然后就可以在任何地方运行它，无论主机是 M1 或 M2 Mac，还是x86 系统或其它系统。
当看到 Arm 和 RISC 开始腾飞时，你会意识到我们的多语言世界在未来五年（甚至更早）只会变得更加丰富。
容器加上 Wasm 看起来像是一个巨大的跨平台胜利。
5 Wasm 和 Kubernetes
关于 Wasm 的另一个争论领域是 Wasm 二进制文件是否应该在本地、与容器一起运行，或者在容器内运行。
但是，只要我们都采用OCI 容器镜像格式，它们都能跑起来。无论是在 Wasm 运行时上本机运行 Wasm 二进制文件，还是在 OCI 容器中运行 Wasm 运行时，你都可以创建一个镜像，然后可以跨多个架构进行部署。
单个镜像可以节省磁盘空间和编译时间，如前所述可以防止测试矩阵失控。在容器内运行 Wasm 的好处是，你可以在对性能影响很小的情况下获得深度防御。与容器并行运行 Wasm 二进制文件的优点仍有待研究，但无论哪种方式，我们都应该能够保留 Kubernetes 生态系统的价值。
如果你想调度 Wasm 容器会变得很容易，首先它们都位于 OCI 注册表中，你可以将它们拉到Kubernetes（或Podman或Docker）中并运行它们。
结论
人们已经知道 Wasm 在浏览器中运行良好。现在是时候对 Wasm 如何在服务器端工作感到兴奋了。
我们仍在了解 Wasm 可能会变成什么样子，但特别令人兴奋的是它的跨平台潜力。Wasm 与容器相结合，能否真正兑现最终可移植性的承诺？我认为这是可能的，但作为技术专家，我们必须拭目以待，并引导它去往我们需要的地方。
Wasm 在后端仍然处于新兴阶段，而且大多尚未经过测试。继续关注 Wasm 的进展并思考它如何使我们每个团队受益非常重要。
Wasm性能真的会和裸机一样好用吗？即使使用新的系统界面，Wasm 也会保留足够的安全性来实现多用户吗？
让我们在未来的几个月或几年里一起找出答案。
