WebAssembly
Arquitetura
Runtime
Desenvolvimento Web
Edge Computing

浏览器之外的 WebAssembly:缺失的通用执行层

为什么 WebAssembly 作为一种通用执行格式很重要,而不仅仅是作为在浏览器中运行 Rust 的一种方式。

浏览器之外的 WebAssembly:缺失的通用执行层

大多数开发人员第一次听说 [WebAssembly0] 时,都会以一种简化的方式进行解释:它用于在浏览器中运行 C 或 Rust 代码,性能接近原生。没错,这只是冰山一角。

最近几年发生的事情比重型网页游戏更有趣。 WebAssembly 或 Wasm 已成为一种可移植的字节码格式,可以在浏览器外部、服务器上、边缘、数据库内部运行,作为插件系统和第三方代码的隔离层。

当您不再将 Wasm 视为前端功能并开始将其视为通用编译目标时,对话就会发生变化。它不再是一个实现细节,而是一个架构决策。

WebAssembly 到底是什么

Wasm 是堆栈虚拟机的二进制指令格式。您可以将高级语言(Rust、C、C++、Go 以及越来越多的其他语言)的代码编译为这种格式,并且任何兼容的运行时都可以运行它。

使其有价值的特性不仅仅是速度。它是三件事的结合:环境之间的真正可移植性、默认隔离以及工件的紧凑大小。

可移植性意味着相同的二进制文件可以在浏览器、Linux 服务器、极简容器和边缘设备上运行,而无需为每个目标重新编译。运行时对平台进行了抽象。

隔离意味着 Wasm 模块在封闭的盒子中运行。它无权访问主机进程的文件系统、网络或内存,除非主机明确授予此访问权限。该模型默认是拒绝的,与继承所有进程权限的本机库相反。

紧凑的尺寸很重要,因为 Wasm 模块很小并且启动速度很快。没有数百兆字节的容器映像或冗长的启动过程。

为什么它不再是浏览器的事情

概念上的转折点出现在一个名为 WASI 的接口上,即 WebAssembly 的系统接口。它定义了 Wasm 模块如何以标准化方式在浏览器之外与外部世界(文件、时钟、网络、环境变量)进行通信。

在 WASI 之前,Wasm 一切都依赖于浏览器 API。随之而来的是一个平台中立的合约。服务器上的运行时实现了 WASI,突然之间,在浏览器中运行的相同二进制文件在服务器主机上运行,​​并且对资源的访问受到控制。

这解锁了 Wasm 作为通用目标的想法。浏览器只是可能的环境之一,而不是唯一的环境。

该领域出现的成熟运行时(Wasmtime、WasmEdge、Wasmer 等)将 Wasm 视为服务器上的一流执行单元。它们加载模块、应用资源限制、授予特定功能并执行,所有这些都比上传容器或传统虚拟机的开销低得多。

这在哪里改变了架构

考虑一下运行不是您编写的且不完全信任的代码的问题。第三方插件、客户提交的功能、平台扩展、用户定义的自定义规则。

这个问题的传统解决方案是昂贵的:容器、操作系统沙箱、隔离进程、轻量级虚拟机。所有这些都有效,但会影响启动时间、内存消耗和操作复杂性。

Wasm 提供了更细粒度的替代方案。您可以在同一进程中的隔离模块内运行不受信任的代码,从几微秒开始,并使用虚拟机模型本身定义的安全边界。

这开辟了三个值得系统设计者关注的领域。第一个是优势:需要立即启动并扩展到许多地理位置的功能受益于 Wasm 的大小和启动速度。第二个是产品可扩展性:您可以让客户编写自定义逻辑并在您的平台中安全地运行它。三是多运行时执行:同一个组件在不同环境中运行,无需重写。

这些前沿领域中的每一个都值得深入分析,我在其他文本中探讨了[详细的边缘案例1]和[插件和沙箱的案例2]。

Wasm 不是什么

调整预期是值得的,因为热情往往会压倒技术现实。

Wasm 不会取代您的整个后端。它是一个执行单元,而不是一个应用程序框架。您仍然需要编排、持久性、[可观察性3] 以及所有其他设备。

Wasm 并不神奇地比本机代码更快。在许多情况下,它的运行方式接近本机,但存在翻译开销和堆栈机器模型的限制。与容器相比,真正的性能优势更多在于启动时间和密度,而不是原始吞吐量。

Wasm 在集成方面仍然存在缺陷。访问系统资源、线程、对 Wasm 目标的每种语言的全面支持、调试工具:所有这些都已经发展,但与整合的本机生态系统的成熟度并不相同。在下大赌注之前,有必要了解[组件模型的局限性4]。

Wasm 并没有免除安全工作。默认情况下的隔离是一个坚实的基础,但如何授予功能、限制资源以及审核模块的功能仍然是架构师的责任。

如何考虑收养

评估 Wasm 的有效方法不是抽象地问它是否比其他技术更好。它正在确定可移植性、隔离性和快速启动的特定组合在哪里解决了您的替代方案无法解决的问题。

如果您需要以细粒度运行不受信任的代码,Wasm 是一个强有力的候选者。如果您需要在异构环境中运行相同的工件而不需要重新编译,那么 Wasm 可以满足您的需求。如果您需要以最小的启动延迟扩展到多个点的功能,那么 Wasm 会很适合。

如果您的系统中不存在这些压力,则可能不存在紧迫性。采用 Wasm 是因为它很有趣,但没有减轻具体的痛苦,是一种产生债务而没有回报的决策。

战略解读很简单:Wasm 是一个可移植且安全的执行层,像这样的层很少是主角。它们是解锁用例的基础设施。当您有正确的用例等待时,价值就会出现。

对于技术团队来说,现在最好的投资是了解功能模型,针对实际问题对服务器运行时进行实验并进行测量。该技术已经足够成熟,可以走出实验室,而且足够早,充分了解它是一种竞争优势。

如果您领导架构并正在权衡这个决定,那么在制定路线图之前值得阅读[当 WebAssembly 真正获得回报时]。

另请阅读

  • [Next.js App Router:默认思考服务器指南6
  • [WebAssembly 和可移植组件:组件模型的承诺7
  • [WebAssembly 处于边缘:为什么快速启动和隔离很重要88
  • [面向领导者的 WebAssembly:当架构决策值得时9
  • [边缘计算:为什么分布式处理将重新定义您的架构10
  • [边缘计算架构:分布式处理策略11