WebAssembly 使用场景和未来发展趋势

1. 前言

从之前的章节学习中，我们已经了解了 WebAssembly（WASM） 的基本概念，以及它的基本使用方法。但是，在什么样的场景中我们会使用 WASM 呢？在这些不同的场景下，我们是如何使用 WASM 的呢？更进一步，我们能看到的 WASM 的未来发展趋势是什么样的呢？在这一章中，为了使读者能够更好更全面的了解 WASM ，我们将会讨论一下 WASM 的使用场景和未来发展趋势。

2. 场景

WASM 的名称的体现了它在最初的设计中人们对它的希望：能够在 Web 环境中快速地运行。目前，WASM 已经能够在包括浏览器在内的很多不同的环境中运行。这些场景包括：云原生场景、移动设备、物联网、区块链等多种不同的场景。在这些场景中，大家使用 WASM 的主要目标包括，但是不限于如下几个方面：

• 加速基于浏览器的应用运行速度，来在一定程度上替代 JavaScript。

• 作为应用沙盒环境（Sandbox）嵌入到应用程序中，为宿主环境（Host）提供一定的安全保障。

• 提供一种插件系统的实现，为产品最终用户提供一定的扩展能力。

• 将不同的编程语言编译成 WASM 来提供它们之间的互操作的可能。

下面两张图分别展示了 1. WASM 在不同场景中的使用情况；2. 主要场景从 2021 年到 2022 年的变化。它们均出自《The State of WebAssembly 2022》[1]。首先第一张图显示了目前大家使用 WASM 的主要领域。从图中我们可以发现，目前大部分的用户都在浏览器端和云原生场景，而 Web 场景的开发更是占到整体的 50% 以上。

图 1. 不同领域 WebAssembly 占比

下一个图中则显示了与去年（2021）年相比，WASM 在不同领域中的占比变化。从图中可见，WASM 在云原生场景中的使用占比从2021年到2022年有了比较大的增长。虽然 Web 场景的使用有略微减少，但是目前它仍然是主要的 WASM 的使用领域。

图 2. 2021-2022 不同领域的占比变化

在不同的领域中， WASM 有着不同程度的应用。目前，有大量的公司和组织在使用 WASM 或者参与 WASM 生态的建设。这些公司或者组织的列表如下图所示[2]：

图 3. WebAssembly 生态中的主要公司和组织

对于具体的场景，我们会在本章节中接下来对它们进行进一步的深入介绍。

2.1 Web 环境

WASM 从最早设计的时候目标是让代码在浏览器端更快地执行。在浏览器环境中，WASM 将非 JavaScript 的语言（例如：C/C++，Rust，Golang等）的代码编译为低级字节码 WASM 模块，浏览器可以直接执行这些模块，而无需解析源文件。

虽然 WASM 是一个相对来说比较新的技术，但是目前在主流浏览器中都已经支持。下图显示了不同浏览器中的 Web 程序集对 WASM 的支持[3]。这里不同的行描述了不同 WASM 的对象在不同浏览器中的支持。例如：Memory 对象代表了 WebAssembly.Memory 对象，该对象是一个可变大小的 ArrayBuffer 或者 SharedArrayBuffer。它内部的原始数据可以被 WebAssembly.Instance 对象访问。

图 4. 不同浏览器中的 WebAssembly 支持

2.1.1 视频解码和GUI控件

WASM 可以用于视频解码和 GUI 控件。例如：1. 在 WASM 中实现的视频解码器可以用于在浏览器中播放视频；2. 在 WASM 中实现的 GUI 控件可以用于在浏览器中渲染图形界面。

目前 HTML5 支持的视频格式主要是三种：MP4, WebM 和 Ogg。进一步需要注意的是，不同浏览器的支持不尽相同。例如：在 Safari 浏览器上，Ogg 格式是不支持的。WebM 只在 58% 的浏览器上支持。在 Firefox 24 之上，MP4 的支持默认情况是被禁用的。

正因为这些，视频平台需要需要解决如何在网页中播放其它格式视频的问题。一般来说，解决方案有如下几种：

1. Flash 播放器（目前已经很少人使用 Flash ）。

2. Web 实现一个播放器。

3. 对视频解码成 MP4 格式再使用原生播放器。

对于爱奇艺、腾讯等公司的直播业务，他们使用了上述第三种方式[4]。当 FLV 格式的直播流到达前端时，使用 WASM 将 FLV 转封装为 MP4 格式，再交给原生播放器。从爱奇艺的技术博客中的描述我们可以知道，由于之前使用的是 JavaScript，其运行效率较低，这部分的性能一直都不太令他们满意。在引入了 WASM 技术之后替换 JavaScript 来进行转封装之后，他们发现浏览器中播放视频的性能提高了将近 20%。下图为爱奇艺直播使用 WASM 之后的性能提高。

图 5. 爱奇艺直播使用 WebAssembly 之后的性能提高

在图形渲染方面，一个使用 WASM 的例子就是 Qt。Qt 是一个跨平台的 C++ 库，它可以用于开发桌面应用程序和移动应用程序。Qt 主要用来开发图形用户界面（Graphical User Interface，GUI）程序，当然也可以用来开发不带界面的命令行（Command User Interface，CUI）程序。从 Qt 5.11.0 发布时，WASM 的支持开始作为 Qt 5.11 工具包更新的一部分发布[5]。

Qt for WebAssembly 的目标是为任何安装了支持 WASM 浏览器的平台编译部署 Qt 应用到 Web 服务器上，不再需要对于不同的系统（例如：Mac, Windows 等）进行编译并进行部署。这样编译一次并部署到 Web 服务器上之后，不同平台的用户都能够使用编译好的 Qt 程序。下图为一个Qt for WebAssembly 应用程序运行的例子。

图 6. Qt for WebAssembly 应用程序运行的例子

其它一些应用则使用 WASM 来提供了一种基于浏览器的使用体验，包括 Figma、AutoCAD、Google Earth。这里我们重点讲一下 Figma。

Figma 最近 200 亿美元被 Adobe 收购。究竟为什么一个面向专业用户、不到十年的一个设计软件，能值这么多钱，而另外一个类似的和 Figma 竞争的软件 Sketch 却在竞争中败阵下来？一个重要的原因就是 Sketch 是一个原生 MacOS 应用，只能在苹果电脑上安装运行，没有免费版。Figma 则是一个浏览器应用，只要有浏览器就能使用，而且有免费版。下图是浏览器打开 Figma 时的样子：

图 7. Figma 浏览器界面

使用 WASM 后，Figma 提高了他们的响应和载入速度。下图为在 Firefox 之上 Figma 的载入时间在 WASM 和 asm.js 之间的不同。我们可以看到，在使用 WASM 后，大文档的载入速度有了明显的提高。

图 8. Figma 在 Firefox 之上的载入时间

2.1.2 浏览器平台的虚拟现实（VR）和游戏相关

几乎每个人都玩过计算机上的游戏，但是在浏览器上玩游戏的人却很少。这是因为浏览器上的游戏曾经通常都是使用 Flash 或者 Java Applet开发，而目前这两种技术都已经被淘汰了。如今，WASM 可以让游戏开发者在浏览器上开发游戏，而不需要使用 Flash 或者 Java Applet。这样，游戏开发者就可以在浏览器上开发游戏了。

最近虚拟现实（VR）技术也很火热，很多人都想在浏览器上体验虚拟现实。WASM 可以让开发者在浏览器上开发 VR 应用，使得用户不需要下载安装任何软件就可以在浏览器上体验虚拟现实。

主流游戏引擎（虚幻，Unity）都已经支持编译目标为 WASM 。在发展早期，asm.js 曾是在浏览器环境运行这些引擎的解决方案。因为 WASM 解决了 asm.js 的痛点，相比之下速度更快，代码更少，使用内存量更少，所以现在 WASM 成为它们在浏览器环境中的默认编译目标。

在游戏方面，基于 WASM 的游戏中，最有名的就是移植的《毁灭战士 3》（ Doom 3 ）。它是一款恐怖的第一人称射击游戏，最初于 2004 年在微软的 Windows 系统上发行。《毁灭战士 3》使用了 Id Tech 4 游戏引擎（更常称之为 Doom 3 引擎），该引擎是于 2011 年根据 GNU 通用公共许可证协议发布的。这款游戏获得了巨大的商业成功，销量超过了 350 万份。在 2018 年，它被移植到浏览器平台。下图为 Doom 3 浏览器平台运行界面：

图 9. Doom3 在 Web 平台运行界面

一般来说，编译为本地代码的应用程序性能要高于基于浏览器的编译版本。在虚拟现实（VR）场景中，响应速度是非常重要的。为了解决浏览器版本的延迟问题，人们会倾向于使用 WASM 。在 Khomtchouk 的论文《 WebAssembly enables low latency interoperable augmented and virtual reality software 》中，就使用了 WASM 来提供了一个很有前途的解决方案，可为基于浏览器的应用程序带来近乎本地化的低延迟性能，通过在任何 WiFi 或支持蜂窝数据网络的 AR/VR 设备上运行的 WASM 的字节码实现大规模硬件不可知的互操作性。

2.1.3 其他基于 Web 环境的应用

除了上述例子之外，在浏览器环境中 WASM 还有很多独特的应用。在 Java 方面，TeaVM 将 Java 字节码编译成 JavaScript 和 WASM 的 AOT 编译器（翻译器）并最终在浏览器中运行。TeaVM 不需要 Java 源文件，它直接将编译好的.class文件编译成 JavaScript 和 WASM 。下图表示了 TeaVM 的编译方式。因为是基于 Java 字节码来编译的，所以 TeaVM 对于 Kotlin 和 Scala 同样也适用。

图 10. TeaVM 使用例子

在数据库方面，DuckDB-WASM 是一个用于浏览器的进程内分析 SQL 数据库。它可以使用 Arrow 语言，读取由文件系统 API 或 HTTP 请求支持的 Parquet、CSV 和 JSON 文件，在主流浏览器上均经过测试。

物理引擎方面，Box2d 是一个优秀的 2D 物理引擎，Box2d-WASM 将 Box2d 编译成了 WASM ，从而可以在浏览器环境中使用。在他们的 GitHub 页面上有该引擎的动态演示。

图 11. Box2d-WASM 运行的例子

2.2 云原生场景（ Cloud Native ）

云原生是一种基于容器的应用开发和部署方式，它的目标是将应用程序打包成容器，然后将容器部署到云平台上。云原生的应用程序可以在任何地方运行，包括本地计算机、云平台、边缘计算设备等。云原生的应用程序可以通过 Kubernetes 等容器编排工具进行管理，从而实现自动化的部署、扩展、监控等功能。

WASM 作为一种新兴的技术，可以在云原生场景中发挥重要作用。在云原生场景中，WASM 可以用于编写云原生应用程序，也可以用于编写云原生的基础设施。在这个章节中，我们将介绍 WASM 在云原生场景中的应用，包括云原生应用及其分发、云原生平台能力、边缘计算和函数无服务计算（ FaaS/Serverless ）。

2.2.1 云原生应用

在云原生时代，Kubernetes 已经成为分布式环境下资源调度和应用编排的事实标准，Kubernetes 可以屏蔽底层设施的差异性。Kubernetes 可以在同一个 K8s 集群中包含 x86、ARM 等不同体系架构的节点，同时支持 Linux，Windows 等不同的操作系统。WASM 和 Kubernetes 相结合可以进一步提升应用的可移植，我们在下面会介绍两种主要的方式来完成 Kubernetes 对 WASM 的编排，分别是 使用传统容器以及使用 Krustlet。

2.2.1.1 传统容器（ Container ）

在介绍传统容器的使用之前，我们先了解一下什么是容器。容器是一种轻量级的虚拟化技术，它可以将应用程序和它的依赖打包在一个文件中，然后在不同的环境中运行。容器的优势在于它的轻量级，可以在不同的环境中运行，而不需要额外的虚拟化层。容器的缺点在于它的性能较差，因为它需要在宿主机的内核上运行，而不是直接运行在硬件上。

这是有别于传统的虚拟机技术，虚拟机技术可以在不同的硬件架构上运行，而不需要额外的虚拟化层。但是虚拟机技术的缺点在于它的性能较差，因为它需要在宿主机的内核上运行，而不是直接运行在硬件上。

下图展示了容器和虚拟机的区别：

图 12. 容器和虚拟机的区别

在 2022 年 10 月底，Docker 宣布推出与 WASM 集成 ( Docker + WASM ) 的首个技术预览版，并表示公司已加入字节码联盟 ( Bytecode Alliance ) ( Bytecode Alliance 是 WASM 和 WebAssembly System Interface 背后的非营利组织)，成为投票成员。目前开发者已经可以通过最新版的 Docker 快速构建面向 WASM 运行时的应用程序。

Docker Engine 继续使用与整体生态相统一的 Containerd 容器运行时，但创建了一个新的 Containerd Shim， 把负责容器进程运行的 runC 替换成 WasmEdge 运行时，Wasm Module 的启动和运行都依赖于 WASM 运行时环境，详情请见下图。这部分是和 WasmEdge 合作的项目，这个 Containerd Shim 从 OCI artifact 中提取 WASM 模块，并使用 WasmEdge 运行时来运行。虽然这里使用了 WasmEdge , 理论上可以把这部分扩展到 Wasmtime 等其他的 WASM 运行时。

图 13. Docker+WASM

2.2.1.2 Krustlet

在介绍 Krustlet 之前，我们先了解一下什么是 Kubernetes。Kubernetes 是一个开源的容器编排引擎，它可以自动部署、扩展和管理容器化的应用程序。Kubernetes 由 Google 公司在 2014 年开源，目前已经成为 CNCF 基金会的核心项目之一。下图展示了 Kubernetes 的架构：

图 14. Kubernetes 架构

在 Kubernetes 中，Kubelet 是一个守护进程，它负责管理容器的生命周期，包括创建、启动、停止、删除容器。Kubelet 通过与 Kubernetes Master 通信来获取容器的创建、启动、停止、删除等指令。Kubelet 通过与 Docker 通信来创建、启动、停止、删除容器。

微软的 Deis Labs 在 2020 年宣布了 Krustlet 项目，Krustlet 是 “Kubernetes RUST kubeLETs”的简称，它为 WASM 代码提供了一个新的沙盒环境，是一个用于将 Kubernetes 管理的工作负载交付给 WASM 运行时的工具。它采用了新的编程语言实现 Kubernetes 的核心组件 Kubelet。相比于 Kubelets 用 Go 编写，Krustlet 是在 Mozilla 的类型安全和内存安全 Rust 中开发的。

Krustlet 可以被视为 Kubelet 的替代实现，但是 Krustlet 专注于管理 WASM ，而不是使用传统容器。我们可以理解为重新用 Rust 实现了一遍 Kubelet 的功能，它使用与 Kubelet 相同的机制，通过 List and Watch 监听 Pod 信息，管理 Pod 生命周期，同时将 Host 级别的数据等管理指标汇报给 APIServer。在 Kubernetes 架构中同时拥有 Kubelet 和 Krustlet，同时在一个集群中管理 容器 和 WASM 。

从成熟度角度来看，个人认为 Krustlet 还是一种概念验证，因为它还不支持 Pod Events 或 Init 容器等特性。WASM 的应用程序必须实现 WASM 系统接口 (WASI)，目前跟传统容器的功能还不能全部对齐，而单独为了 WASM 重写一套 Kubelet 感觉并没有那么有必要，所以整体来看这种方式来支持 WASM 局限非常多。截止 2022 年11月，Krustlet 目前也不再积极维护中。

2.2.2 云原生应用分发

为了部署云原生应用，我们需要将应用的镜像分发到集群中，然后通过 Kubernetes 的调度器将应用部署到集群中。在 WASM 中，目前仍然没有一个统一的分发方式，目前主要有两种方式：通过第三方的分发平台，或者通过将 WASM 代码打包成镜像的方式。

WAPM 全称是 WebAssembly Package management。是目前社区提供的类似 NPM 的包管理实现，来专门支持 WASM 制品的分发。我们可以在这个仓库上 发布自己的 WASM 程序，或者下载运行别人发布的 WASM 程序。它由 Wasmer 公司创建于 2019 年，作为一个开源项目，帮助 WASM 开发者轻松分享打包的代码模块。

2.2.3 云原生平台能力

云原生平台能力是云原生应用的基础，包括：服务发现、负载均衡、服务网格、日志监控、配置管理、安全等。目前 WASM 在这些领域的支持还不够完善，但是社区也在不断的完善中。在这里，我们需要重点介绍的是 Envoy Proxy 和 Istio。

Envoy 是一个高性能、可编程的L3、L4和L7代理，它是 Istio 的核心组件，也是 Istio 的数据平面。Envoy 本身是一个 C++ 项目，但是在 2021 年 10 月份，Envoy 官方发布了 Envoy WASM 扩展，支持在 Envoy 中运行 WASM 程序。Envoy WASM 扩展的目的是为了让开发者能够在 Envoy 中运行 WASM 程序，来实现自定义的功能。Envoy WASM 扩展的实现是基于 Proxy-WASM ，Proxy-WASM 是一个通用的 WASM 运行时，它提供了一套标准的 API，来让开发者能够在不同的 WASM 运行时中实现跨平台的功能。

下图展示了 Istio 中包含 Envoy Proxy 的架构图[6]。在每个节点，Envoy Proxy 作为 Sidecar 与应用程序一起运行，Envoy Proxy 会与 Istio 控制平面进行通信，来获取配置信息，以及上报应用程序的运行状态。Envoy Proxy 会根据配置信息，来实现服务发现、负载均衡、服务网格、日志监控、配置管理、安全等功能。

图 15: Istio 中的 Envoy 架构

下图展示了 Envoy 使用 WASM 扩展的架构图[7]。Envoy WASM 扩展是基于 proxy-wasm 实现的，它提供了一套标准的 API，来让开发者能够在 Envoy 中运行 WASM 程序。

图 16: Envoy 使用 WASM 扩展

2.2.4 边缘计算（ Edge Computing ）

过去几年，云计算的边界不断向边缘侧延伸。作为云原生技术事实标准的 “ Kubernetes + 容器”组合，自然也被很多人考虑部署到边缘侧，以提高边缘应用部署的效率和便利性，降低边缘应用与硬件之间的耦合度。不过 “ Kubernetes + 容器” 组合并非万用良药，对于边缘计算场景来说，它们还是太重了。

边缘设备通常硬件资源有限，没有足够的资源部署运行完整的 Kubernetes。其他问题还有：很多边缘设备基于 ARM 架构，但大部分 Kubernetes 发行版不支持 ARM 架构；边缘设备所处环境复杂，无法保证稳定可靠的网络连接，而 Kubernetes 不支持离线运行，等等。为了解决包含但不限于以上 Kubernetes 在边缘计算场景下的挑战，更好地将 Kubernetes 从云端延伸到边缘，业内已经诞生了多个基于原生 Kubernetes 优化的开源项目，比如华为开源的 KubeEdge、阿里开源的 OpenYurt、腾讯开源的 SuperEdge、Rancher 开源的 K3s 等，并且这四个项目都已经被 CNCF 接收。

而传统容器方案比如 Docker，问题与 Kubernetes 类似，它还是一个相对重的容器运行时，镜像大小很容易就达到一两百 MB 以上，对于资源不足的硬件——边缘场景有不少内存和磁盘空间小于 1GB 的微型设备，Docker 也不是一个理想的选择。

边缘计算不仅需要更轻量的 Kubernetes，也需要更轻量、更快的容器方案，WASM 就是近几年出现的一个新选择。

2.2.4.1 Fastly

Fastly 在 2019 年开源了 Lucet 项目，首次将 WASM 从主流浏览器场景带到边缘之上，这个项目演化成了今天最流行的 WASM 运行时和编译器之一 Wasmtime，作为最早在边缘场景落地 WASM 运行时的边缘云厂商，Fastly 将 lucet(Wasmtime) 整合到边缘计算平台 Compute@Edge，为边缘上 serverless 计算提供了安全隔离和高密部署的体验，平均启动时间在 82µs，并达到接近于 0 的内存启动消耗。如下图所示为 Fastly 提供的启动沙箱分配内存耗时的性能测试[8]。

图 17: Fastly 沙箱启动时间分布

在语言支持上，Compute@Edge 通过 WASI 实现对不同语言接口支持，用户可以根据 Compute@Edge hostcall ABI 使用对应的 WASI 工具生成对应的自定义 SDK ，实现了两个基本的( fastly_http_req, fastly_http_body )接口后，用户可以在应用中使用基于抽象二进制接口（ABI）自定义的 SDK ，并在 Compute@Edge 中启动。更多的实例可以参考[9]。

除此以外，Compute@Edge 提供了丰富的工具链，包括运行时的实时日志记录以及对每个 WASM App 的请求跟踪的能力。

2.2.4.2 Cloudflare Workers

Cloudflare 在边缘平台服务的运行时 Cloudflare Worker 中加入了对 WASM 的支持，基于 V8 引擎进行改进，提供了安全隔离的沙箱环境，通过统一的控制面和元数据存储，同时提供了进程级别的管理和流量调度能力。如下图所示[10]：

图 18: Cloudflare Worker 整体架构

作为 WASM 的运行时，Cloudflare Worker 支持 C/C++，Rust 等多语言在边缘上的函数计算。Cloudflare 认为 WASM 主要适用于计算密集型任务，如图片处理和数学计算。一个简单的例子可以参考[11]。

2.2.5 函数计算/无服务器计算（ FaaS/Serverless ）

函数计算/无服务计算（FaaS / Serverless）是一种基于事件驱动的计算模型，用户可以通过事件触发函数的执行，函数执行完成后，用户可以根据需要选择是否保留函数的执行结果。它通过将计算资源抽象为函数，将函数的执行与事件的触发解耦，从而实现了计算资源的弹性伸缩和按需付费。

Serverless 将会在接下来的十年里，迅速地被采用，得到迅猛的发展。Serverless 计算将会成为云计算默认的计算范式，并取代 Serverful（传统云）计算模式

在 Serverless 计算中，现有的主流技术是利用沙箱容器技术，如 AWS Firecracker 或者阿里云沙箱容器，来实现强隔离的安全执行环境，但是也带来更大的资源消耗。虽然现在阿里云沙箱容器经过优化可以实现 300ms 的冷启动速度，接近 Docker 这样的 OS 容器启动速度，但是还无法满足函数 PaaS 毫秒级的启动要求，目前需要通过的调度策略，预留一定的 Standby 实例才可以满足，但是这样也引入了更多的资源消耗。

WASM 所具备的的安全、可移植、高效率，轻量化的特点，为应用沙箱的发展带来了全新的思路。WASM 可以轻松实现毫秒级冷启动时间和极低的资源消耗。同时 WASM 字节码比原生机器码有更高的安全级别。此外，WASI 实现了细粒度基于能力的安全模型，遵循最小权限原则。在执行过程中，WASI 应用只能访问由依赖注入指明的确切资源集，这种方式与传统粗粒度的操作系统级隔离相比，进一步收敛了安全攻击面。

腾讯云在 2020 年发布的 SCF Custom Runtime（自定义运行时）可以支持用任何编程语言编写的函数，每个函数通过托管自定义的运行时，提供函数服务。腾讯云与 Second State ( WasmEdge ) 合作，提供了一个 ServerlessAI 推理的函数模板，添加了类 WASI 的扩展 wasi-tensorflow，使 TensorFlow 模型能够以硬件速度运行。WASM 虚拟机在这个过程中提供了安全性、可移植性和开发者易用性。具体例子可以参考在腾讯云上部署基于 WASM 的高性能 serverless 函数的例子[12]。

AWS 同样在 Lambda 中支持了将 WasmEdge 作为 Docker Container 沙盒环境进行接入，用户可以使用 Rust 编译好的 WASM Module 构建镜像并上传，将本地测试通过的 WASM 应用部署到 AWS Lambda 之上，并提供与常规 AWS Lambda 相同的 Serverless 服务体验，完整例子在[13]。其架构为下图所示：

图 19: WS 在 Lambda 中引入 WasmEdge 作为 WASM 函数运行时

2.3 移动设备、IoT 和物联网

之前的段落我们大篇幅介绍了在云原生环境中 WASM 的应用，但是 WASM 的应用场景并不仅限于云原生环境，它还可以应用于移动设备、IoT 和物联网等场景。随着移动设备的发展，移动设备的性能也在不断提升，但是移动设备的计算能力仍然远远不及 PC 端，而 WASM 的出现，可以让移动设备上的应用具备更高的性能，同时也可以让移动设备上的应用具备更高的安全性。

IoT 刚刚走入人们视野的最初几年，我们一般只能通过诸如 C/C++ 甚至是汇编语言来为这些物联网嵌入式设备编写软件程序。后来，随着互联网技术的不断发展，以及从易用性、流行程度、生态系统等其他多方面的考虑，诸如 JavaScript 、Lua 以及 Python 等高抽象层次的语言也被逐渐应用在嵌入式设备上，“性能”可能不再是人们选择嵌入式设备编程语言时所需要考虑的第一要素。但现实情况是，并不是所有的嵌入式设备都可以满足这些高抽象层次语言虚拟机在其上流畅运行的要求。并且在考虑功耗以及应用环境等情况时，它们的性能和易用性便开始捉襟见肘。而此时， WASM 字节码的高密度、高性能以及高可移植性使得我们有了可尝试的新选择。

一些公司已经在此领域开始了尝试。三星在其 Tizen Studio 中支持使用 WASM 开发运行在其基于 Tizen 系统的智能电视( Smart TV )上的应用。小米公司则在自研的基于 NuttX 的 VelaOS 物联网操作系统之上支持了 WASM Micro Runtime（WAMR） 轻量 WASM 运行时。在天猫精灵，他们开发了面向 AIoT 场景的高性能应用开发框架 Waft。Waft 将不同语言开发的 App 编译为统一的基于 WASM 的 Waft App，并在不同的平台上运行。

2.4 区块链技术

这几年，数字货币的概念被炒的火热。一批数字货币的忠实信徒和投机者参与到了这场基于区块链技术的数字货币的狂欢中，最后导致了一系列经济和社会问题。

然而，仅从技术角度来看，区块链技术有它独特的优势。毫无疑问，比特币是区块链技术应用最被人熟知的例子。比特币开创了去中心化密码货币的先河，然而比特币并不完美，其中协议的扩展性是一项不足。比特币协议里使用了一套基于堆栈的脚本语言，这语言虽然具有一定灵活性，使得像多重签名这样的功能得以实现，然而却不足以构建更高级的应用，例如去中心化交易所等。以太坊从设计上就是为了解决比特币扩展性不足的问题。

以太坊在拥有比特币网络中基本的数据存储功能之外，还需要运行各种代码进行计算，由以太坊虚拟机（ EVM ）所编译和解释执行的软件或者应用就是“智能合约”。当以太坊链上发生转账交易的时候，以太坊虚拟机（ EVM ）会进行以下一系列工作：

• 调取转账的数值，分析合约的指令。

• 计算 Gas 的消耗（手续费）, 确保发出转账的地址有足够的 Gas 费。

• 执行合约，实现转账到对应的地址。

以太坊的原生的 EVM 在使用中暴露了不少的问题：

• EVM 处理如此多不同的操作并不快，但是它的操作码规范还没有发展到可以处理变化的需求。

• 未能进化意味着语言也有局限性。

在新的版本中，它提供一个基于 WASM 的 eWASM 文件格式。可以把认为是下一代虚拟机的技术标准。如何理解 eWASM 呢？下面的公式解释了eWASM：

eWASM = WASM - 不确定性(浮点运算) + 计费 + EEI方法(用来和以太坊沟通)

那么在以太坊虚拟机上使用 WASM 有什么优势呢？主要这里有三点：1. 速度；2. 预编译；3. 灵活性/互操作性。

速度方面，EVM 只能处理 256 位字节码，而 WASM 直接转换为编译代码，能够更快的加载。预编译方面，EVM 依赖预编译，WASM 不需要预编译，执行起来更加高效，开发者可以创建高效快速的智能合约，而不用担心潜在的硬分叉。在灵活性/互操作性上，WASM 支持更多的语言编译成 WASM 代码，并且提供了比 EVM 更广泛的工具集。

总的来说， 除了以太坊以外，Cosmos 和 Polkadot 也都在其区块链上使用了 WASM。很多人相信 WASM 在未来将会成为去中心化应用开发的基础层。

2.5 其它场景

Fluvio

Fluvio 是一个用于实时数据的高性能分布式流媒体平台。他们实现了编写对流数据进行内联操作（ inline operations ）的自定义代码的功能。该功能被称为 SmartModules。它由 WASM 提供支持，尽可能轻量和高性能。

图 20. Fluvio 架构

Deno

Deno 是一个 JavaScript/TypeScript 的运行时，默认使用安全环境执行代码，有着卓越的开发体验。Deno 建立在 V8、Rust 和 Tokio 的基础上。跟 Node.js 一样，Deno 也是一个服务器运行时，但是支持多种语言，可以直接运行 JavaScript、TypeScript 和 WASM 程序。

它内置了 V8 引擎，用来解释 JavaScript。同时，也内置了 tsc 引擎，解释 TypeScript。它使用 Rust 语言开发，由于 Rust 原生支持 WASM ，所以它也能直接运行 WASM 。它的异步操作不使用 libuv 这个库，而是使用 Rust 语言的 Tokio 库，来实现事件循环（event loop）。

相比于 Node.js，Deno 提高了 Node.js 的安全性。这主要是由于 Deno 在默认情况下不允许程序访问磁盘、网络、子进程或环境变量。

WasmCloud

WasmCloud 是一个旨在帮助开发人员创建安全、可移植和可重用组件（称为 Actor ）的平台。它利用 WASM 实现极高的可移植性，来对用户软件提供保护、部署、维护、观察和升级的能力。同时在这个过程中尽可能减少用户需要复制粘贴的和业务无关的代码。

2.6 未来发展

目前 WASM 还在快速发展阶段，仍然存在一些需要解决的问题和增添更多的特性，例如：单指令多数据流（SIMD）、异常处理、并发、垃圾收集等。同时，其性能和本地代码相比，很多场合仍然有一定的差距。

• 更好的开发体验

  最初阶段，开发人员在企业级利用 WASM 所需的环境一直是比较复杂的。WASM 的开发者体验并不舒适（例如，调试 WASM 仍然是众所周知的困难）。在整个开发生命周期中，在编译到 WASM 和以实际方式利用 WASM 方面，有大量的空间可以提供更好的工具。同时大多数开发人员不具备低级语言和技术的专业知识，这也是 WASM 的一个障碍。这些问题都需要解决，才能让 WASM 成为企业级应用的首选。

• 标准的继续推进

  虽然社区有一些分裂意见（例如，见 AssemblyScript 决定放弃对 WASI 的支持），但是 WASM 标准的活力依然重要。除了蓬勃发展的创业生态系统，微软、亚马逊、谷歌、 Fastly 、 Cloudflare 、 Mozilla 等科技巨头也开始认识到 WASM 是支持下一代云工作负载的有效底层，他们正在积极为标准机构和非营利组织（如 W3C 和字节码联盟）做出贡献，以推动这个社区的发展。CNCF 也在发挥重要作用，接受 wasmCloud 和 WasmEdge 作为沙盒项目。仍有重要的工作要做；像文档，如垃圾收集、本地 DOM 访问、套接字、线程、组件模型等，都在激烈讨论中。标准的总体目标是使 WASM 更适用于更多的目标，并适用于更多的使用案例。

• 编程语言支持

  虽然 WASM 最常被吹捧的好处之一是多语言支持，但目前支持的现实状态是介于两者之间。像 C++ 、Go （包括 TinyGo ）和 Rust 这样的语言已经接受了 WASM ，但一些最常见的语言，如 Python 、 Java 和 PHP 还在努力实现一等公民的地位。为了真正实现主流采用， WASM 的支持必须继续扩展到一些更复杂的语言，并向最广泛采用的语言扩展。

• 理念、传播和社区

  正如我们在容器和协调引擎（如: Kubernetes ）的案例中看到的那样，开发者对 WASM 的采用可以通过布道者和更广泛的、成熟的倡导者社区来进一步推动。像云原生计算基金会（ CNCF ）和字节码联盟这样的组织已经走在了吸引开发者的前列，以促进对 WASM 相关项目、活动和倡议的参与。除了开发者受众，其他利益相关者对 WASM 的认识可以通过阐述二阶价值主张来推动，例如在云和 Serverless 环境中使用 WASM 可能带来的成本节约。

3. 总结

至此，我们已经讨论了 WASM 在各种不同场景的应用和未来的发展趋势。如果非要拿出一个类似的技术来让读者对 WASM 更加有一些直观的理解的话，那么我们可以把 WASM 理解成为更有潜力的一个 Java 语言的竞争者。当然， WASM 还处在发展的初期，还有很多不完善的地方。但是，只有这样，我们才有更多的机会来探索和发现更多的可能性，不是吗？这里是一片蓝海，我们可以在这里创造属于我们自己的价值。

4. 参考文献

[1]. 《The State of WebAssembly 2022》: https://blog.scottlogic.com/2022/06/20/state-of-wasm-2022.html
[2]. 《The Wasm Application & Infrastructure Landscape》: https://sapphireventures.com/blog/whats-up-with-webassembly-computes-next-paradigm-shift/
[3]. 《WebAssembly》: https://developer.mozilla.org/en-US/docs/WebAssembly
[4]. 《爱奇艺直播 WebAssembly 优化之路》: https://cloud.tencent.com/developer/news/464897
[5]. 《Qt for WebAssembly 技术预览版发布 Beta 版本》: https://www.codercto.com/a/15920.html
[6]. 《Envoy教程》: https://www.amoyw.com/2021/03/05/envoy/
[7]. 《Write WASM filters for Envoy and deploy them in ASM》: https://www.alibabacloud.com/help/en/alibaba-cloud-service-mesh/latest/write-wasm-filters-for-envoy-and-deploy-them-in-asm
[8]. 《The lifecycle and performance of a Lucet instance》: https://www.fastly.com/blog/lucet-performance-and-lifecycle
[9]. 《Custom SDKs on Compute@Edge》: https://developer.fastly.com/learning/compute/custom/
[10]. 《Cloudflare Docs: Security model》: https://developers.cloudflare.com/workers/learning/security-model/
[11]. 《Cloudflare Docs: Hello World in Rust》: https://developers.cloudflare.com/workers/tutorials/hello-world-rust/
[12]. 《在腾讯云上部署基于 WebAssembly 的高性能 serverless 函数》：https://juejin.cn/post/6994377781979283470
[13]. 《WebAssembly serverless functions in AWS Lambda》: https://www.cncf.io/blog/2021/08/25/webassembly-serverless-functions-in-aws-lambda/
[14]. 《虚拟机之战：WASM与EVM|万向区块链小课堂》: https://www.panewslab.com/zh/articledetails/D28830508.html
[15]. 《WASM 将引领下一代计算范式 [译]》: https://www.oschina.net/news/214580