WebAssembly – Where is it going?

“WebAssembly is a safe, portable, low-level code format designed for efficient execution and compact representation” – W3C.

本文章介绍WASM与WASI的应用场景,这些场景中已经有一些探索性的项目进行中,这些项目中隐含了未来应用架构与分发的模式。本文翻译自《WebAssembly – Where is it going?》,作者为 MATEUS PIMENTA

从 WASM 到 WASI

WebAssembly (Wasm) 在2017年被主流浏览器支持的时候,代表着一种更快的(接近本地)在浏览器中运行计算机程序的技术标准成形。

不过,当 Mozilla 在 2019年发布 WebAssembly System Interface (WASI) 之时,这是一个革命性的时刻。WASI 解除了 WASM 仅浏览器运行中的限定,扩展到了作为一个独立的虚拟运行环境,可运行在主机上。这代表着一种全新的计算机应用程序编码、打包、运行的技术的诞生。

运行在浏览器中的WASM

在2017年 WASM 被主流浏览器(Microsoft Edge, Safari, Google Chrome and Firefox)支持之后,W3C起草了一个WASM标准并很快的进入”recommendation“状态,并在2019年正式发布。这意味着开发者可以在浏览器中以”接近本地程序性能“运行重负载的程序,不受JavaScript引擎性能限制、也没有跨浏览器适配问题。

在浏览器中使用WASM,开发者可以继续使用JavaScript开发传统的页面程序,同时将重负载的功能卸载到WASM编码的程序中,通过 WebAssembly JS API 交互。

游戏

游戏是WASM最初始的目标场景,当得到一些游戏引擎公司的支持之后,(如 Unreal游戏引擎 宣布支持WASM),牵引了WASM的技术构建方向。当然,WASM不仅仅用于游戏场景,在 图像处理视频处理音频处理工作室,这些场景下的工作当前只能在桌面或服务器上完成。

人工智能模型推理

人工智能的模型推理也是WASM的一个典型场景。端侧的应用程序脱离服务端,直接加载复杂的模型,例如人脸识别,语音转文字,在端侧完成推理。所有的复杂逻辑都脱离了JavaScript,以Native Code方式运行。

Tensorflow.js 项目为此场景提供了一个WASM应用程序,Tensorflow.js还可以使用 multithreading and Single Instruction Multiple Data (SIMD) 技术加速计算。如果 WASM 的 Threading 与 SIMD 规范发布,一些新的项目将会随之出现用于工程化这些技术。

两个重要变化

在浏览器中执行重载计算的技术会带来两个显著变化。

  1. 软件公司会开发更多的Web客户端应用程序。这种交付模式,相比较于软件包安装到用户端的机器上,能够简化应用程序的升级、安全补丁等维护工作。这个变化会更进一步加强SaaS这种商业模式。
  2. 在客户端运行重载计算,相比较于Client-Server模式,消除了客户端与服务器端的运行时交互,用户体验会有一个越阶提升,同时也会减少软件厂商的网络、计算费用。

超越浏览器的WASM

当前,WASM只能在浏览器沙箱里运行Native Code。但是WASI规范中定义了WASM沙箱与主机系统的文件、网络等交互的接口规范。这个能力允许我们在WASM沙箱中运行通用的应用程序,且可以获得可移植性、安全性等WebAssembly引入的特性。这里面隐含了深刻的内涵,我们逐一解读。

容器与容器编排

Docker 创始人 Solomon Hykes 发表过一个声明:如果 WASM 与 WASI 早几年出现,就没有Docker什么事了。当然,这个并不表示立马要把当前所有的docker运行负载使用WebAssembly替换,但是这个表明了WebAssembly可以弥补当前docker容器的一些缺陷。

同时,主流的容器托管产品(AWS ECS, AWS Lambda (now with containers!), Google Cloud Run, Azure Containers Instances),都开始将WebAssembly作为一种替代传统容器的技术启动研究。 更进一步,微软的 Deis Labs 已经有了个 Krustlet 项目,可以将WebAssembly放到K8S中编排。

WebAssembly相对与传统的docker container,有几个优点。

  • 安全。 即便当前的container在安全领域有很多的防护手段,但是机制上,应用进程是可以直接访问到host主机的内核,因为container是通过cgroup实现的一种轻量级虚拟化技术,并不是完整内核虚拟化。虽然有 security context 机制,但是攻击面还是很大。当前也有一种使用完整内核虚拟化的趋势,包括 gVisor, Firecracker(AWS Lambda, AWS Farget产品都使用此虚拟化技术), Kata。这表明安全是很重要的一个考量因素。 WebAssembly 的安全模型是完整沙箱,这表明系统调用可控,内存安全,以及更少的攻击面。

  • 包大小。 容器镜像包大小一直是一个诟病点,由此出现了很多技术点以及最佳实践用于减少镜像包大小。这是因为机制上,容器镜像要求将内内核之外的、应用程序依赖的lib库都打包到镜像中,其目的是实现可移植性。 WebAssembly的交付包只包含应用程序本身(实际情况还会有15%的压缩)。 包大小减少后可以实现更短时间启动应用程序,如缩短函数计算中的”冷启动”时间。Fastly的Lucent叠加AOT技术,冷启动时间约 50微秒;Cloudflare 使用 V8引擎,冷启动时间 5毫秒。这对Serverless计算场景是非常重要的体验提升。

边缘计算

云厂商边缘计算服务已经应用了有些年了, AWS Lambda@EdgeCloudflare Workers 都是基于JavaScript引擎运行用户代码,现在WebAssembly提供了一个新的选项。

基于前面讨论的WebAssembly的有点,结合CND厂商的PoP点(point-of-presence),一种新的分布式计算应用架构正在形成。这种模式应用不仅能提升用户体验,还有显著的韧性属性、以及减少数据中心的网络与计算负载。

到目前为止,已经有厂商提供了基于WebAssembly的边缘计算服务。

嵌入式,IoT,移动应用,机器学习等

WASM正在被更多的领域采用。你可以集成WASM到应用程序中,比如在允许用户上传代码的应用,如规则引擎,可以使用WebAssembly评估规则代码的安全性。 Wasmer 估计是当前最好的 WASM 运行时。

在IoT领域也有一些 WASM 运行时,如 wasm-micro-runtimewasm3 ,这些运行时降低了代码在不同设备上流转的复杂度。 wasm3 还支持 Android 与 iOS 设备。

Intel的工程师正在开发 wasi-nn ,这项工作的目的是使得机器学习代码在不同架构上流转更容易。

当前所处的阶段

WASM 在浏览器领域的应用相关技术已经基本成熟。WASI 规范也在稳步演进中,一些模块已经实现了,新的特性也在不断迭代中。在变成语言领域,已经有不少语言支持编译为WebAssembly字节码,且越来越成熟

在浏览器之外,除边缘计算之外,WASM还处于早期阶段,并不能立马替换container,最先出现的形式是混合编排,根据不同业务场景编排container与WASM。

WASI标准还在4个阶段中的第2个,WebAssembly/WASI性能提议也在审议中。

生态方面还需要一些考量,近期由WebAssembly 4 个sponsor 成立的字节联盟致力与WASM与WASI的生态发展。

尝试一下

webassembly.studio

wasm.fastlylabs.com

Reference

WebAssembly-Wiki

WebAssembly

WebAssembly – Where is it going?

关注公众号获得更多云最佳实践