shubham shaw

近十年来，我部署企业软件的思维模式一直围绕容器展开，容器是一种将应用程序及其运行所需的所有操作系统文件打包在一起的轻量级包。最近，我决定走出 C# 和传统云环境的舒适区，探索一项采用根本不同方法的技术：服务器上的 WebAssembly。

大多数工程师都知道 WebAssembly，常简称为 Wasm，它是一种二进制指令格式，是一组紧凑的机器可读代码，旨在让 Rust 或 C++ 等语言在网络浏览器内以接近原生的速度运行。吸引我兴趣的是 Wasm 如何走出网页，进入服务器基础设施，尤其是在边缘计算中，即在物理上靠近用户的服务器上处理数据，以减少网络延迟。

这种转变依赖于一项名为 WASI 的新标准，即 WebAssembly 系统接口，这是一套标准化规则，允许 Wasm 程序与宿主服务器的文件系统、时钟和内存安全交互，而无需浏览器。您可以将 WASI 想象成一个安全的翻译器，它允许沙箱程序向操作系统请求特定资源，而不会让该程序访问机器的其余部分。

来自多年管理企业微服务的经验，微服务是小型、独立的软件服务，通过网络进行通信，设计理念上的差异令人震惊。传统容器携带大量额外重量，因为它们包含底层操作系统的一部分。它们通常占用数百兆字节的磁盘空间，并且需要明显的延迟才能启动。另一方面，WebAssembly 二进制文件仅包含编译后的应用程序逻辑。它通常只有几兆字节，并且在不到一毫秒的时间内开始运行。

将传统容器想象成装满货物的卡车，需要时间来停车、卸货和设置才能开始工作。WebAssembly 二进制文件更像是轻量级的弹出式帐篷，在您打开的瞬间就会弹出。

在我最近使用 Rust 和服务器端 Wasm 运行时编写简单后端服务的实验中，冷启动性能非常出色。冷启动是服务器启动应用程序的新实例以处理传入流量时的初始延迟。能够在适度的硬件上以几乎零延迟和最小的内存消耗启动数百个隔离任务，为事件驱动的工作流程开辟了令人兴奋的可能性。

同时，探索新兴技术意味着遇到真正的权衡。该生态系统仍处于生命周期的早期阶段。调试正在运行的 Wasm 二进制文件尚未提供成熟的企业开发环境所提供的流畅、逐步体验。此外，已建立的数据库驱动程序和遥测库（用于记录系统活动和跟踪错误的工具）仍在针对 Wasm 环境进行调整。

我预计 WebAssembly 不会很快取代传统容器用于所有企业工作负载。相反，它感觉像是工具箱中一个强大的新工具，特别是对于高密度、低延迟的任务，瞬时启动时间至关重要。花时间了解这个生态系统的工作原理，是对服务器架构中创新空间仍然很大的一个很好的提醒。

对于跟踪后端基础设施变化的工程师，您目前是否在浏览器之外测试 WebAssembly，哪些缺失的功能或工具差距阻碍您在项目中使用它？

webassembly #rust #backend #devto