博客 | 首席技术官办公室

WebAssembly 在浏览器之外可行吗?

奥斯卡·斯宾塞缩略图
奥斯卡·斯宾塞
2024 年 11 月 26 日发布

简而言之,是的。

WebAssembly(Wasm)已成为席卷 Web 开发的主导技术。 从早期的技术演示(例如完全在浏览器中运行的流行游戏《毁灭战士》)到大型传统应用程序(例如在普通网页上提供完整桌面式体验的 Photoshop),WebAssembly 在已经安装在世界上每台个人计算机上的熟悉程序中提供了全新的体验。

Wasm 的设计目的是让几乎任何编程语言都能支持它,无论用户的计算机使用哪种类型的处理器,并且它具有几个有利的安全属性,浏览器可以使用这些属性来防止未授权访问用户的数据或系统资源。 事实证明,这些属性在浏览器之外非常有用,特别是当想要单独运行代码或超便携代码时。

Unix 上的 POSIX 的故事

默认情况下,WebAssembly 无法访问其运行系统的任何资源。 这只是对零和一的纯粹操作,这就是为什么我们看到 Wasm 主要用于计算繁重的任务,比如解码视频或处理图像,而不是全面的应用程序开发。 让 WebAssembly 沙盒访问外部功能(例如有关当前时间或存储在文件中的数据的信息)相对容易,但具体使用哪些 API 往往因应用程序而异。

Unix 系统经历了与浏览器之外的 WebAssembly 类似的情况。 许多应用程序需要访问常见的系统资源,例如网络和文件系统,但每个操作系统的实现方式略有不同。 因此,POSIX 作为标准的可移植操作系统接口而首次出现——所有类 Unix 系统都可以采用该接口来标准化程序与操作系统的通信方式。 这也使得设计在一个类 Unix 系统上运行的程序可以轻松移植到另一个系统上运行。

进入 WASI,即 WebAssembly 系统接口

为了给 WebAssembly 程序与操作系统通信提供标准方式,WASI(WebAssembly 系统接口)诞生了。 WASI 很大程度上受到了一个名为 CloudABI 的项目的启发,而 CloudABI 又受到了 POSIX 的启发。这为 WebAssembly 在浏览器之外大放异彩打开了无限可能 — 用户现在可以同时拥有 WebAssembly 的所有安全性和沙盒属性以及精心设计的 API,从而访问常见的系统资源,同时又不会完全失去沙盒功能。 自然而然地,我想到了一种类似的技术——容器。 如果没有参考 Docker 联合创始人 Solomon Hykes 分享的关于 WASI 的最深刻的帖子之一,那么关于这个话题的讨论就不算完整:

这话确实没错。 WebAssembly 提供了一种可移植的方式来打包代码,该代码可以在任何平台上以接近本机的速度安全运行,并且与容器相比还有一个额外的好处,那就是根本不需要任何操作系统。 大多数容器开发人员生产的容器都具有某种 Linux 操作系统,程序在其中运行,容器大小通常为数百兆字节或几千兆字节。 WebAssembly 二进制文件是纯代码,大小通常以千字节或个位数兆字节为单位。 想象这样一个世界似乎很疯狂:开发人员不再随处部署容器,而是部署 WebAssembly,但这一现实已经开始实现,目前有多个项目正在积极开发以在 Kubernetes 上运行 Wasm。

生产中的服务器端 WebAssembly

许多公司已经从生产中的服务器端 Wasm 中受益。 Cloudflare 和 Fastly 都拥有庞大的边缘计算网络,允许客户在世界各地尽可能靠近用户部署代码。 两者都策略性地选择了 WebAssembly,因为它具有小型、超便携的二进制文件、快速的启动时间和稳定的多租户特性。 一家新兴公司 Cosmonic 使用巧妙的网络技术,让 WebAssembly 组件无论在哪里运行都能无缝地相互通信,无论是掌中的微型设备还是在世界另一端运行的机器。 另一家新贵 Fermyon 使用 WebAssembly 大幅增加服务器工作负载密度。 其结果是服务器成本大幅降低并且地球的计算更加绿色。

浏览器之外的增长

总而言之,尽管 WebAssembly 最初是为浏览器内计算而开发的,但在浏览器之外仍然表现出很高的可行性。 它的设计支持各种编程语言并强调安全性,使其成为独立运行代码和实现可移植性的绝佳选择。 WASI 的引入使得服务器端 WebAssembly 蓬勃发展,使组织能够利用 Wasm 提供更好的产品,同时大大提高成本效益。 WebAssembly 在浏览器之外的潜力不仅仅是一个想法,而是一个行业正在成长的现实。

要了解更多信息,请参阅我们之前的博客文章“为什么你应该关心 WebAssembly ”。

另外,请观看或收听我们的“WebAssembly Unleashed”播客