WebAssembly(WASM) 和云原生 | wasm和区块链

Posted 2023-04-07 西京刀客

文章目录

• • 一、什么是Wasm、WASI
  • 二、WebAssembly(WASM) 和云原生
  • • WebAssembly 能不能取代 Docker
  • 三、Wasm container 与 Kubernetes
  • 四、云原生、WASM和边缘计算
  • • 为边缘优化的 WebAssembly 虚拟机: wasmedge
  • 五、wasm和区块链
  • • Wasm对于EVM有什么优势？
    • 虚拟机之战：WASM 与 EVM

一、什么是Wasm、WASI

Wasm，即WebAssembly，是一种用来补充JS在运行上不足的“低级”语言——基于二进制编写。其目标之一正是达到在网页上如同运行机器语言一样快速高效。其开发团队分别来自Mozilla、Google、Microsoft、Apple。

Wasm允许用户采用自己熟悉的语言书写（目前支持C/C++/Rust），再在虚拟机引擎在浏览器上运行。它支持沙盒模式，即先用高级语言编写wasm模块，再在JS中以库函数加载。

WebAssembly，我们都知道，是一种新的字节码格式，目前被应用于 web 中，由于其可移植、体积小，安全性的等优点被渐渐广泛认可，但是其主要是运行在浏览器中。

一些天才们，想让 WebAssembly 也可以运行在非浏览器环境中，这就产生了 WASI。

WASI是一个新的API体系, 由Wasmtime项目设计, 目的是为WASM设计一套引擎无关(engine-indepent),
面向非Web系统(non-Web system-oriented)的API标准.

二、WebAssembly(WASM) 和云原生

说到 WebAssembly 最初与 Docker、云原生产生关联，就不得不提 Docker 联合创始人 Solomon Hykes 在 2019 年 3 月份发布的一条推文。他在推文中表示：如果 WASM（WebAssembly）和 WASI（WebAssembly System Interface, WASM 系统接口）在 2008 年就已经存在，那就没有必要创建 Docker 了。

在这条动态里，他说如果 Wasm + WASI 在 2008年就存在了，就没有必要创建 Docker了，Wasm 是云计算的未来。

很多人只看到了这一句话，没有看到他后面补发的内容，他说 WebAssembly 不会取代 Docker，Docker 与 WebAssembly 会肩并肩运行。

随着Wasm的发展，WebAssembly system interface（简称Wasi）出现了。WASI代表WebAssembly系统接口。这是由Wasmtime项目设计的API，可提供对几种类似操作系统的功能的访问，包括文件和文件系统，Berkeley套接字，时钟和随机数。

此时Wasm的沙箱机制带来的隔离性和安全性，都比Docker做的更好。

Wasm已经成为了云原生项目的扩展利器，并且非常有可能成为云原生工作负载的最佳运行时。

WebAssembly已经成为2021年增长最快的云原生趋势之一。

WebAssembly 能不能取代 Docker

Docker 联合创始人 Solomon Hykes 推特说，如果 Wasm + WASI 在 2008年就存在了，就没有必要创建 Docker了，Wasm 是云计算的未来。
很多人只看到了这一句话，没有看到他后面补发的内容，他说 WebAssembly 不会取代 Docker，Docker 与 WebAssembly 会肩并肩运行。

WebAssembly 与 Docker 不是一个取代关系。WebAssembly 与 Docker 是各有所长、互相补足的关系，就像之前提到的，WebAssembly 对工具链要求比较高，但是 WebAssembly 的性能高、轻量级、安全的特点会让 WebAssembly 用在今天 Docker 进不去的场景。

举个具体的例子，WebAssembly 在冷启动方面，能够比 Docker 快100倍。所以 Docker 很难满足 的边缘计算、轻服务、汽车、区块链，都是 WebAssembly 的用武之地。

三、Wasm container 与 Kubernetes

WebAssembly崛起，Kubevirt成主流，2022年云原生的五大发展趋势
参考URL: http://app.myzaker.com/news/article.php?pk=61edfe9eb15ec0709e1236a0&f=normal
国外原文链接：https://thenewstack.io/5-cloud-native-trends-to-watch-out-for-in-2022/

WebAssembly 已经发展成为一个高性能、跨平台和多语种的软件沙盒环境，被运用于云原生软件组件。由于容器运行时和 WebAssembly（WASM）存在惊人的相似性，所以 Kubernetes 也可以被用于协调 WASM 组件。

WasmCloud、 WasmEdge、KubeEdge 以及 Krustlet 等项目使 WASM 成为云原生宇宙的公民之一。Kubernetes 可以从一个单一的控制平面无缝协调 WebAssembly 和容器两种工作负载，也就是说我们甚至可以将打包成 WebAssembly 的软件与容器化软件一起运行。包括 SecondState, Cosmonic 和 Suborbital 在内的创业公司正在建立的平台和工具，都在加速 WASM 的采用。预计自 2022 年我们可以看到云原生 WASM 的崛起。

四、云原生、WASM和边缘计算

云原生的下一步，或从WebAssembly在边缘取代Docker开始
参考URL: https://weibo.com/ttarticle/p/show?id=2309404751926406546094

过去几年，云计算的边界不断向边缘侧延伸。作为云原生技术事实标准的Kubernetes+容器组合，自然也被很多人考虑部署到边缘侧。不过K8s+容器组对于边缘计算场景来说，还是太过重了。因为边缘设备通常硬件资源有限，没有足够的资源部署运行完整的K8s。

很多边缘设备基于ARM架构，但大部分K8s发行版不支持ARM架构。同时，很多边缘设备所处环境复杂，无法保证稳定可靠的网络连接，而K8s的致命问题就是不支持离线运行。

传统容器方案，比如Docker，问题与K8s类似，Docker镜像大小很容易就达到一两百MB以上，边缘场景有不少内存和磁盘空间小于1GB的微型设备。

Docker 资源消耗大，对边缘设备要求高。

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

云原生的下一步，或从WebAssembly在边缘取代Docker开始! 到2030年，估计有500亿台联网设备将放大我们的工作负荷–这些设备可能很小，可能很便宜–但它们将变得越来越智能和复杂。由于上述原因，WebAssemblies一次编写到处运行，安全模式和可移植性肯定会使它成为未来基础设施的重要组成部分。

为边缘优化的 WebAssembly 虚拟机: wasmedge

官网：https://wasmedge.org/
github： https://github.com/WasmEdge/WasmEdge

五、wasm和区块链

以太坊内核实现了一个图灵完备的虚拟机，即以太坊虚拟机（简称EVM）。它定义了一套通用的、确定性的指令，程序可以被编译成这些指令，并且可以在全世界任何一台计算机上运行。

传统计算机包含的指令集只接受32位或者64位的输入。EVM与此不同并且很特殊，它是一台256位的计算机，故意设计成这样是为了更易于处理以太坊的哈希算法，它会明确产生256位的输出。

然而，实际运行EVM程序的计算机则需要把256位的字拆分成它们的本地架构来执行智能合约，从而使得整个系统变得非常低效和不实用。

WebAssembly，或者简称为WASM，是内存安全、平台独立的，可以完美高效地映射到所有类型的CPU架构上。

使用 WebAssembly，不依赖于EVM，现在我们有了一套优秀并且高效的指令集，可以编译各种类型的语言，并且有信心它们可以在不同类型的平台上执行且具有同等的性能 - 这对于去中心化应用来说是非常理想的！更进一步，通过去除浮点运算指令，WASM指令集可以很容易地变成确定性指令集，从而很适合作为EVM的替代品。

尽管EVM目前算是区块链领域较为完备的机制，但它的局限性和时效性随着区块链发展也显得有些“落伍”，而作为EVM合约升级版的Wasm合约开始受到了众人关注。

以太坊创始人“V神”早就表示以太坊2.0将会升级为Wasm合约（eWASM），以满足更多开发需求。

EWASM团队已经着手在以太坊上集成WebAssembly，从而保证以太坊2.0的执行层更加高效、简单，适合作为完全的去中心化计算平台。https://github.com/ewasm

以太坊不是唯一一家正在调研 WebAssembly 技术的区块链企业。还有很多人都在押注这项技术，包括 Dfinity、EOS、NEAR、和 波卡 等等——它似乎已成为构建新一代区块链网络的事实标准。

作为EVM的发明者同时也是波卡创始人Gavin博士，对这个问题拥有足够的话语权。在做波卡的时候，Gavin并没有沿用自己发明的EVM，而是选择Wasm。

比较新兴的公链会更多的支持Wasm，然后以兼容的形式对接EVM。例如 波卡兼容EVM又支持Wasm，波卡的许多生态项目也是两者皆有。

Wasm对于EVM有什么优势？

以太坊基金会在Devcon上多次说明了自己打算将EVM过渡到Wasm的想法，但已经上线的庞大合约体量无法支持深层次的变革，生态也在这一临时方案上越走越远。选用Wasm作为智能合约的虚拟机的优势有以下几点：

1.完胜EVM虚拟机。相比EVM需要开发者预编译，较高的编程成本，Wasm虚拟机的结构、指令完备性及执行效率远胜于EVM虚拟机，将成为合约开发的新引擎。

2.执行速度快。Wasm有一套完整的语义，且具有紧凑的二进制格式，体积很小，这使得Wasm字节码运行时的效率可以接近于本地机器码的效率，比EVM的性能高1到2个数量级，后期还会升级为更快JIT虚拟机。

3.交易费用低。更快的Wasm虚拟机，致使交易吞吐量大幅提升，那么合约部署和交易成本也能大幅降低。可以说Wasm合约很好的解决了现在以太坊上交易费用高和交易拥堵的问题。

4.合约语言广。Wasm扩展了智能合同开发者可用的语言系列，支持使用任何Wasm的高级语言（如Rust、C++、javascript等）开发编写复杂业务逻辑，这意味着你可以用你熟悉的任何语言编写智能合约，包括最成熟的基于Rust的ink!，或基于AssemblyScript的Ask!等。

集成WASM也可以让那些熟悉Rust和Go之类的主流语言的人更容易进行智能合约的开发，而不是需要学习solidity的各种细节才能在以太坊上开发有用的应用程序。

虚拟机之战：WASM 与 EVM

虚拟机之战：WASM 与 EVM
参考URL: https://m.bimama.com/news/10600.html
英文原文：https://medium.com/momentum6/the-war-on-virtual-machines-wasm-vs-evm-8e68f9d53ef4

WASM 原生时代已经到来 | 解读 WebAssembly 的 2022

Ending定律：一切可编译为 WebAssembly 的，终将被编译为 WebAssembly（Any application that can be compiled to WebAssembly, will be compiled to WebAssembly eventually）。

作者 | 柴树杉       责编 | 梦依丹

出品 | CSDN（ID：CSDNnews）

引子：作者在 2018 年写作《WebAssembly 标准入门》时，有幸邀请到 CSDN和极客帮的创始人蒋涛先生为该书作序，当时蒋涛先生就对 WebAssembly 的技术做出了高度评价。2022 年我们针对 WebAssembly 开源了凹语言，CSDN 平台也在第一时间提供了报道。在此一并感谢CSDN 平台对 WebAssembly 技术推广的支持！

WebAssembly 作为一种新兴的网页虚拟机标准，它的设计目标包括：高可移植性、高安全性、高效率。2018 年 WebAssembly 第一个规范草案诞生，2019 年成为 W3C 第四个标准语言。到了 2022 年底可以说我们已经进入了WASM 原生时代……

Ending 定律和 WASM 原生

1、什么是 Ending 定律

• Ending’s law: “Any application that can be compiled to WebAssembly, will be compiled to WebAssembly eventually.”

• Ending 定律：“一切可编译为 WebAssembly 的，终将被编译为 WebAssembly。”

Ending 定律也称为终结者定律，它是 Ending 在 2016 年 Emscripten 技术交流会上针对 WebAssembly 技术给出的断言。Ending 定律的威力不仅仅在语言层面。WebAssembly 是第一个虚拟机世界标准，以后将人手至少一个 WASM 虚拟机。不过和之前被大家鄙视的 JavaScript 语言大举入侵各个领域的情况不同，这次 Python、Ruby 这些语言将彻底拥抱 WebAssembly 技术，因为它是一个更底层、也更加开放的新兴生态平台。从 Ending 定律可以预测 WASM 原生时代迟早都会到来。

2、什么是 WASM 原生

WASM 原生可以类比云原生的定义：就是天生就是为 WebAssembly 平台设计的程序和语言。比如专门为 WebAssembly 设计的 AssemblyScript 语言和 凹语言就是 WASM 原生的编程语言。如果一个应用天生就是考虑了 WebAssembly 的生态支持，那么就是 WASM 原生的应用。一个 WASM 原生应用很容易支持纯浏览器环境，因此不支持纯浏览器环境的应用大概率不是 WASM 原生。

现在 Docker 已经开始支持 WASM 程序，因此 WASM 原生软件天然也是云原生的软件，但是反之则不能成立。而云原生因为受限于云的环境、导致其应用的场景和领域有较大的限制，比如云原生应用强依赖网络因此无法在很多单片机环境、甚至是本地环境运行，因此云原生更多是在互联网企业流行。但是 WASM 原生的程序则可以轻松在 Arduino 等受限环境、本地台式机机环境、个人智能手机环境和 Kubernetes 等云原生环境执行。可以说未来 WASM 原生应用将无处不在！

WebAssembly 简史

WebAssembly（简称 WASM）是 W3C 定义的第 4 个标准，是 Web 的第四种语言。说 WebAssembly 是一门编程语言，但实际上它更像一个编译器，其实它是一个虚拟机，它还包含了一门低级汇编语言和对应的虚拟机体系结构，而 WebAssembly 这个名字从字面理解就说明了一切：“Web 的汇编语言”。简而言之、WebAssembly 是一种新兴的网页虚拟机标准，它的设计目标包括：高可移植性、高安全性、高效率（包括载入效率和运行效率）、尽可能小的程序体积。

1.1 Emscripten 项目

WebAssembly 的前身是 Mozilla 创建的 Emscripten 项目（2010年）——通过将 C/C++ 通过 LLVM 编译到 JavaScript 的 asm.js 子集来提速！JavaScript作为弱类型语言，由于其变量类型不固定，使用变量前需要先判断其类型，这样无疑增加了运算的复杂度、降低了执行效能。因为 asm.js 仅包含可以预判变量类型的数值运算，有效的避免了 JavaScript 弱类型变量语法带来的执行效能低下的顽疴。根据测试，针对 asm.js 优化的引擎执行速度和 C/C++ 原生应用在一个数量级。

2015 年 6 月 Mozilla 在 asm.js 的基础上发布 WebAssembly 项目，随后Google、Microsoft、Apple 等各大主流的浏览器厂商均大力支持。WebAssembly 不仅拥有比 asm.js 更高的执行效能，由于使用了二进制编码等一系列技术，WebAssembly 编写的模块有更小的体积和更高的解析速度。目前不仅 C/C++ 语言编写的程序可以编译为 WebAssembly 模块，Go、Kotlin、Rust、Python、Ruby、Node.js、AssemblyScript、凹语言等新兴的编程语言都开始对 WebAssembly 提供支持。

1.2 WebAssembly 1.0 草案

WebAssembly 技术自诞生之日就进入高速发展阶段。在 2018 年 7 月 WebAssembly 1.0 草案正式发布，在 2019 年 12 月正式成为 W3C 国际标准，成为与 HTML、CSS 和 JavaScript 并列的唯四前端技术。2019 年，同样诞生了 WASI（WebAssembly System Interafce）规范，用于将基本的系统调用带入到WASM生态。2022年Docker对WASM提供支持，目前 WebAssembly 已经是一个独立的生态。

1.3 WebAssembly 生态大图

下面是 “WebAssembly 将引领下一代计算范式” 展示的生态大图：

可以看到从工具链、基础设施、到应有和 Web3 均有涉及，生态已经非常丰富。正和 JVM 构建的生态类似，WebAssembly 也在构建自己的庞大生态。

WASM 社区 22 年的变化

2022 年，国内外自媒体社区对 WebAssembly 的评价态度可谓是完美遵循了欲扬先抑的剧本。先是有热文爆大佬 WebAssembly 创业失败引发质疑，然后是传出社区分裂、应用争议再引发炒错的方向等争论，然后随着 Docker 对 WASM 支持的预览版发布带来风向 180 度大转弯，简直是要把不明真相的群众彻底忽悠拐了。其实 WebAssembly 从诞生之日起，真正的从业人员始终在稳步推进，完全没有自媒体想象和策划的这些剧本演义。

3.1 WebAssembly 2.0 草案

4 月 20 日，W3C 公布了 WebAssembly 2.0 的第一批公共工作草案。主要包含向量类型、引用类型、多返回值、多 Table 支持、Table 和内存指令增强等。向量类型的支持可以用于优化纯计算类型的并发程序、引用类型可以用于和外部的浏览器 DOM 对象等更好的交互、多返回值可以可以简化某些程序的表示（比如凹语言后端依赖该特性）、多 Table 支持可能用于灵活支持多模块连接等。可以说 WebAssembly 标准是该生态的统一基准平面，而且这些特性的实现已经相对普及，可以作为实验特性试试用。

完整文档参考：https://www.w3.org/TR/wasm-core-2/

3.2 Docker 支持 WebAssembly

2019 年，Docker 创始人 Solomon Hykes 发布了一条推文，他说如果 2008 年就诞生 WebAssembly 和 WASI 的话，Docker 就没有必要诞生了。

其实作者在 2018 年写作《WebAssembly 标准入门》时， 通过推演也得出过类似的结论：当时的结论是 WebAssembly 更大的生命力在浏览器之外，如果配合文件系统、网络系统将得到一个更为迷你的操作系统无关的运行平台。

Docker 与 WasmEdge 合作创建了一个 containerd shim，该运行时支持运行 WASM 程序。下面是 Docker 对 WASM 的支持原理图：

Docker 执行 wasm 需要指定一些额外参数：

$ docker run -dp 8080:8080 \\
    --name=wasm-example \\
    --runtime=io.containerd.wasmedge.v1 \\
    --platform=wasi/wasm32 \\
    michaelirwin244/wasm-example

首先 runtime 参数指定 wasmedge 运行时，然后 platform 指定采用 wasi/wasm32 规范（指定有哪些宿主 api）。

完整的信息可以参考 Docker 的官方文档：https://docs.docker.com/desktop/wasm/

3.3 SQLite3 官方支持 WebAssembly

SQLite3 作为一个纯粹的 C 语言库，其实在 WebAssembly 标准诞生之前就可以通过 Emscripten 技术将 C 代码编译为 asm.js。因此，网上很早就有在浏览器的 JS 版本、甚至直接通过 Emscripten 输出 WebAssembly。不过这次是 SQLite3 官方提供了对 WebAssembly 的支持，这表示 WebAssembly 在 SQLite 社区完全进入工业级应用阶段！

根据官网介绍，主要有 4 个目标：

• 绑定一个低级的 sqlite3 API，在使用方面尽可能接近原生 API；

• 更高级别的面向对象风格 API，类似于 sql.js 和 node.js 样式的实现；

• 基于 Worker 的 API，以支持多线程环境更容易使用 SQLite 功能；

• 基于 Worker API 的 Promise 包装，对用户完全隐藏了跨线程通信方面复杂性。

而不在此列的特性包括不支持 UTF 16、和清除老旧特性等。简而言之，在提供底层 API 能力的同时，针对面向对象、多线程等环节提供简单易用的 API。完整的介绍请参考：https://sqlite.org/wasm

3.4 Ruby 3.2 支持 WebAssembly

12 月发布的 Ruby 3.2 也增加了基于 WASI 的 WebAssembly 支持。使得 CRuby 二进制内容可用于浏览器、Serverless Edge、以及其他 WebAssembly/WASI 嵌入环境。目前，此功能已通过除 Thread API 之外的 basic 和 bootstrap 测试套件。

虽然目前基于安全原因，还缺少一些功能来实现纤程、异常和垃圾回收的特性，但是这已经让用户可以在浏览器中尝试原生的 CRuby：https://try.ruby-lang.org/playground/

3.5 Python 3.11 支持 WebAssembly

和 Ruby 社区的目标类似，Python 社区也在 4 月启动在 Python 3.11 增加对 WebAssembly 的支持。Python 3.11 对 wasm32-emscripten 和 wasm32-wasi 提供了支持，从而也实现了在浏览器执行 Python 的梦想。

具体细节可参考以下文档：

• https://pythondev.readthedocs.io/wasm.html

• https://docs.python.org/3/library/intro.html#webassembly-platforms

• https://speakerdeck.com/tiran/python-3-dot-11-in-the-web-browser-a-journey-pycon-de-2022-keynote

因为有了 WebAssembly 魔法加持，Ruby 和 Python 等脚本语言也终于可以在浏览器玩耍了。

3.6 为 WebAssembly 而生的凹语言

WebAssembly 草案刚刚发布不久，国外就诞生了专门为其设计的 AssemblyScript 语言。在2022年7月，国内 Gopher 也发起了针对 WebAssembly 平台的凹语言。目前凹语言不仅仅提供了在线的 Playground，还上线了用凹语言开发的贪吃蛇小游戏。希望新兴的语言可以为 WebAssembly 注入更多的活力。

• 凹语言主页：https://wa-lang.org/

• 凹语言仓库：https://github.com/wa-lang/wa

• 凹语言开发的贪吃蛇：https://wa-lang.org/wa/snake/

WASM 虚拟机实现

对于 JavaScript 用户，直接通过浏览器内置的 WebAssembly 模块即可，或者是通过 Node.js 提供的模块 API。我们这里简要介绍的是浏览器环境之外的 WASM 虚拟机实现，这里介绍的主要有 C/C++、Rust 和 Go 语言几类实现。总体来说，大家完全不需要担心 WASM 虚拟机的选择和切换代价，只要遵循 WASM 标准原则切换虚拟机就和换个鼠标一样容易。

4.1 C/C++ 语言 - WasmEdge、wasm3 和 WAMR

WasmEdge 和 wasm3 是 C/C++ 语言实现的具有代表性的两个 WebAssembly 虚拟机（没有包含 V8 的虚拟机）。

WasmEdge 可以说是目前最受关注的 WebAssembly 虚拟机实现，因为它不仅仅是 CNCF 推荐的 WASM 虚拟机，更是 Docker 内置的 WebAssembly 虚拟机。WasmEdge 是由美国的袁钧涛（Michael Juntao Yuan）发起，是由 CNCF 托管的云原生 WebAssembly runtime。它广泛应用于边缘计算、汽车、Jamstack、Serverless、SaaS、服务网格，乃至区块链应用。WasmEdge 可以进行 AOT （提前编译）编译器优化，是当今市场上最快的 WebAssembly runtime 之一。可以预计，随着 Docker Wasm 的普及，WasmEdge 将成为最流行的 WASM 虚拟机实现之一。

• WasmEdge：https://wasmedge.org

• 袁钧涛（Michael Juntao Yuan）：https://github.com/juntao

wasm3 是 C 实现的 WebAssembly 引擎，可运行在嵌入式设备上。因为需要的资源比较少，目前可以运行在Arduino和树莓派环境。

• wasm3 仓库：https://github.com/wasm3/wasm3

由 Mozilla、英特尔、RedHat 和 Fastly 公司宣布成立字节码联盟（Bytecode Alliance）开发的 WebAssembly Micro Runtime（WAMR）也是一个非常优秀的虚拟机实现，其提供AOT、JIT等多种不同的优化手段，底层也是依赖LLVM后端的一些能力。

• WAMR的仓库：https://github.com/bytecodealliance/wasm-micro-runtime

4.2 Rust 语言 - wasmer 和 wasmtime

wasmer 和 wasmtime 是 Rust 实现的两个流行的 WebAssembly 虚拟机。根据 2022 年 7 月的调查报告（300人提交问卷）显示，来自字节码联盟的 wasmtime 最流行、其次为 wasmer。不过从长期看，作者推测 WasmEdge 将随着 Docker/wasm 成为浏览器外最流行的 Wasm 虚拟机实现。

• wasmtime 仓库：https://github.com/bytecodealliance/wasmtime

• wasmer 仓库：https://github.com/wasmerio

4.3 Go 语言 - WaZero

WaZero 是纯 Go 语言实现的 WebAssembly 虚拟机，因此不需要依赖 CGO 特性。目前凹语言内置的就是 WaZero 虚拟机。

仓库地址：https://github.com/tetratelabs/wazero

另外，国内张秀宏著的《WebAssembly 原理与核心技术》讨论了用 Go 语言如何实现 WebAssembly 虚拟机，感兴趣的读者可以参考。

支持 WASM 的编程语言

WebAssembly 允许开发者用几十种编程语言（包括 AssemblyScript、C/C++、Rust、Golang、JavaScript 和凹语言等）编写应用程序。支持  WASM 的编程语言主要分为 3 类：

1. 首先是专门为 WebAssembly 设计的新语言，比如 AssemblyScript 和凹语言等；

2. 其次是将语言编译到 WebAssembly 目标平台，比如 C/C++、Rust、Golang 这类语言（和第一类有一定重叠）；

3. 最后是将语言的虚拟机或解释器编译到 WebAssembly 平台，比如 Lua、JavaScript、Ruby和Python这些。

除此之外，还有一些其它的领域语言也在支持 WebAssembly 平台。

• 支持 WebAssembly 的语言列表：https://github.com/appcypher/awesome-wasm-langs

5.1 JavaScript —— WebAssembly 替换的目标

JavaScript 开始其实是 WebAssembly 要替换的目标。但是随着 WasmEdge 等引擎支持 QuickJS 的解释器，JavaScript 逐渐变成了 WebAssembly 平台之上的最流行的编程语言。这里除了有 JavaScript 语言用户比较多的因素，同时 JavaScript 的单线程模型也非常契合 WebAssembly 的单线程模型（只是相对于 Python 等支持多线程的脚本语言，套娃的性能损失至少 10 倍起）。JavaScript 和 WebAssembly 无限套娃的事情真在切实发生，同时 JavaScript 也失去了浏览器中的霸主地位，降级为普通公民。

5.2 AssemblyScript —— 为 WebAssembly 而生的 TypeScript

AssemblyScript 是一个把 TypeScript 语法搬到 WebAssembly 的编译器。它目前是 WebAssembly 环境非常受欢迎的一个语言。AssemblyScript 只允许 TypeScript 的有限功能子集，因此不需要花太多时间就可以上手。同时它与 JavaScript 非常相似，所以 AssemblyScript 使 Web 开发人员可以轻松地将 WebAssembly 整合到他们的网站中，而不必使用完全不同的语言。

下面是一个 AssemblyScript 程序，和 TypeScript 几乎是一样的：

export function add(a: i32, b: i32): i32 
    return a + b;

不过 AssemblyScript 只有 WebAssembly 支持的基本类型，而复杂的类型通过内置库实现。同时为了提供灵活的扩展能力，AssemblyScript 编译器提供了扩展能力。

• AssemblyScript 主页：https://www.assemblyscript.org/

5.3 C/C++ —— WebAssembly 为其而生

C/C++ 是 WebAssembly 该技术前身 Emscripten 诞生时的初始目标。Emscripten 项目，尝试通过 LLVM 工具链将 C/C++ 语言编写的程序转译为 JavaScript 代码，在此过程中创建了 JavaScript 子集 asm.js，asm.js 仅包含可以预判变量类型的数值运算，有效的避免了 JavaScript 弱类型变量语法带来的执行效能低下的顽疴。其中的核心魔法使 WebAssembly 和 C/C++ 采用相似的线性内存模型，提供为 JIT 提供了转化为相似代码的可能。

5.4 Rust 语言 —— 基于 LLVM 的输出 WebAssembly 能力

Rust 和 Emscripten 都诞生于 Mozilla 公司，因此目前 WebAssembly 社区和 Rust 社区有着很大的重叠部分。很多 Rust 实现的 WebAssembly 虚拟机，同时 Rust 编译器借助 LLVM 的能力输出 WebAssembly 模块。可以说 Rust 技术的发展和抱住 WebAssembly 这个大腿有极大的关系。当然，因为 Rust 兼容 C/C++ 内存模型同时又无 GC 依赖，使得 Rust 可以构造出非常轻量高效的 WASM 模块。不过 Rust 本身的超高门槛也为初学者带来了极大的挑战。

5.5 Go 语言 —— 独立的 WebAssembly 后端

Go 语言作为云计算等领域的主流语言，从 Go1.11 开始，WebAssembly 开始作为一个标准平台被官方支持，这说明了 Go 语言官方团队也认可了 WebAssembly 平台的重要性和巨大潜力。目前 Go 语言社区已经有众多与 WebAssembly 相关的开源项目，比如有很多开源的 WebAssembly 虚拟机就是采用 Go 语言实现的。不过 Go 语言对 WebAssembly 被诟病的一个方面是官方生成的 WASM 文件不是 wasi 规范，同时因为 GC 等特性导致 WASM 体积比较大。

社区有个针对嵌入式环境等 TinyGo 变种，后端同样借助 LLVM 的能力输出 WebAssembly 模块。不过因为 LLVM 的依赖非常重，导致 TinyGo 的单个命令行将近 100MB、同样的原因导致无法方便在浏览器环境使用。可以说 TinyGo 本身并不 Tiny，只是其目标平台是针对 Tiny 的单片机和 WASM 等平台。

5.6 凹语言 —— 为 WebAssembly 而生的国产语言

凹语言是为 WebAssembly 而设计的新语言，是国内 Gopher 发起的纯社区构建的开源国产编程语言项目。同时凹语言也是国内第一个实现纯浏览器内编译、执行全链路的自研静态类型的编译型通用编程语言。凹语言不仅仅点亮了 Arduino Nano 33 开发板，同时也通过实现了 BrainFuck 虚拟机证明了其图灵完备的能力，最近还验证了通过凹语言开发 Web 版本贪吃蛇的能力。

5.7 KCL —— 向 WebAssembly 迁移的领域语言

Kusion 配置语言（KCL）是由来自蚂蚁的徐鹏飞负责设计的、基于约束的记录及函数语言。KCL 通过成熟的编程语言技术和实践来改进对大量繁杂配置比如云原生场景的编写，致力于构建围绕配置的更好的模块化、扩展性和稳定性，更简单的逻辑编写，以及更快的自动化集成和良好的生态延展性。作为领域语言，KCL 目前也是基于 LLVM 的能力输出 WebAssembly 模块，通过 WebAssembly 模块良好的隔离性和跨平台特性，KCL 可以轻易实现在浏览器当中运行。

KCL 语言的主页：https://kcl-lang.io/

5.8 其它支持 WASM 的语言

比如 Zig 等一些语言也支持 WASM，本质上它们和 C/C++/Rust/TinyGo 一样，都是依赖 LLVM 的输出 WASM 的能力。当然，也有一些采用类似 AssemblyScript 路线，通过 Binaryen 输出 WASM。还有一些特殊场景，比如 OPA 的 Rego 是独立实现输出 WASM 的能力。WASM 虽然和 C/C++ 采用相似的内存模型，但是依然有一些细微的差异，如果希望发挥其最大优势需要从语言设计和后端输出两个方便考虑，这也是很多新语言正在探索的方向。

WASM的一些场景

6.1 Web 应用

随着 WebAssembly 的成熟，Web 应用不在是 JavaScript 的天下。比如之前就有国外大牛基于 WASM 技术将 Windows 2000 搬到了浏览器中。而像 AutoCAD 和谷歌地球这些重量级的应用均通过 WebAssembly 支持了浏览器。

当然，不仅仅是重量级的 Web 应用，随着 WASM 原生编程语言的成熟，可以预期会有更多的其他语言开发的 Web 应用。比如，下面是采用凹语言开发的贪吃蛇小游戏就是基于 WebAssembly：

• 贪吃蛇游戏在线地址：https://wa-lang.org/wa/snake/

6.2 Web3 和元宇宙应用

随着 Web3 和元宇宙概念的兴起，WebAssembly 也将作为其中的关键技术，甚至是基石技术。目前 Web3 相关的区块链行业有大量的技术基于 WebAssembly 构建，甚至专门定制 EWASM 技术标准。而元宇宙作为数字化和现实完全融合的新社会生态，其底层的软件系统更是非常依赖纯开源软件和平台无关的通用技术，因此作者推测 GPL 开源协议和 WebAssembly 技术将会是元宇宙的两大关键支柱。

6.3 Serverless 应用

Serverless 强依赖高度优化的冷启动，Wasm 非常适合作为下一代无服务器平台运行时。SecondState、Cloudflare、Netlify 和 Vercel 等公司都支持通过其边缘运行时部署 WebAssembly 功能。

下图是 AWS Lambda 中的 WebAssembly Serverless 函数工作原理：

具体细节可以参考这个文章：https://www.cncf.io/blog/2021/08/25/webassembly-serverless-functions-in-aws-lambda/

6.4 插件系统应用

得益于 WASM 的跨平台的特性，很多系统和框架在考虑通过 WASM 开发插件系统。比如基于 eBPF 和 Wasm 技术实现给 Linux 打动态的补丁。

比如阿里云刚开源的 Higress 网关的插件系统也支持 wasm，对比传统 Nginx 网关使用 lua 进行扩展，wasm 的多语言和安全沙箱特性带来了革命性的变化。同时对比传统 Nginx 网关，修改 lua 代码后需要 reload 才能生效，Higress 可以实现插件的热分发和热加载，插件逻辑发生变化对流量完全无损，长连接也不会断开。

• 使用 Go 开发 Higress 插件可参考：https://higress.io/zh-cn/docs/user/wasm-go.html

比如蚂蚁开源的 MOSN（Modular Open Smart Network），是一款主要使用 Go 语言开发的云原生网络代理平台。MSON 就支持通过 WASM 插件来扩展其能力。下图是 MOSN 插件的工作原理图：

MOSN 插件的细节可参考：https://mosn.io/blog/posts/mosn-wasm-framework/

6.5 单片机应用

Wasm 不仅仅应用在浏览器、云计算等行业，在边缘计算等嵌入式领域也有应用场景。比如 wasm3 虚拟机就针对 arduino 提供的更精简的虚拟机，用户可以通过 wasm 技术为不同的单片机开发应用。

比如可以通过凹语言结合 wasm3-arduino 来开发 arduino 的例子，下图是本地模拟环境代码和执行效果图：

wasm3-arduino 仓库：https://github.com/wasm3/wasm3-arduino

WASM 教程推荐

WebAssembly 属于这个新生态的根技术、而目前正是处于根技术生态的构建阶段。因此，这类推荐的更多是偏向 WebAssembly 规范、原理和实现的教程。我们希望当 WebAssembly 技术正在普及之后，用户可以通过流行的编程语言直接开发 WebAssembly 应用而不需要关系根技术的细节。

7.1 《WebAssembly 规范》—— 2022

WebAssembly 规范 1.0 草案在 2018 年发布，现在最新的 WebAssembly 2.0 在 2022 年发布。WebAssembly 规范是市面上所有该技术的实现和实践的参与源头。任何希望追根溯源、获取最前沿的 WebAssembly 发展方向的同学不仅仅推荐精读该规范，甚至还建议跟踪规范的讨论和诞生的过程。

该文档并非正式出版的图书，目前规范只有在线电子版，建议自行打印。

7.2 《WebAssembly 标准入门》—— 2018

本书是本文作者和前同事于 2018 年合著，主要讲解了 WebAssembly 的基础知识，其内容涵盖了 WASM 的历史背景、WASM 中汇编语言和虚拟机指令、浏览器对 WASM 的支持、其它高级语言对 WASM 的支持等。

本书适合想要掌握 WebAssembly 技术、构建对应虚拟机工具、编程语言或希望了解底层细节的用户学习。

7.3 《WebAssembly: The Definitive Guide》—— 2021

这是 Oreilly 出版的相对较新的 WebAssembly 专著，不仅仅覆盖了规范本身同时结合了主流编程语言的案例。

目前国内还没有中文版本，大家可以阅读英文版本。

7.4 《WebAssembly 原理与核心技术》—— 2021

这是国内虚拟机实现专家张秀宏写的一本讲述如何实现 WebAssembly 虚拟机的专著。它不仅对 WebAssembly 的工作原理、核心技术和规范进行了全面的剖析和解读，而且给出了实现 WebAssembly 解释器和 AOT 编译器的思路和代码。

对于希望尝试自己实现 WebAssembly 的同学建议阅读本书。

2023 年展望

对于 WebAssembly 来说，2022 年是真正润物细无声开始落地的过程：从新的 2.0 标准到 Ruby、Python 两大主流脚本语言开始官方支持，从 SQLite3 开始官方支持、从 Docker 开始官方支持等，到为其而生的凹语言等，到真正的商业应用都有巨大的发展（而完全不是因为某个大佬的项目黄了就断言  WASM 要凉的节奏）。

在商业应用上，Figma 基于 WebAssembly 打造在浏览器中的高性能应用，后被 Adobe 以 200 亿美元收购，而 Adobe 也在向浏览器迁移。此外，WebAssembly 也是云厂商、边缘计算和 Serverless 的候选人。

随着 WebAssembly 的普及，有一些相关技术流行趋势也日趋明朗化。作者做 2 个小小的趋势预测：

1. 首先是 WasmEdge 将成为浏览器外最流行的运行时；

2. 其次是 JavaScript 将成为 WebAssembly 平台上最流行的编程语言。

不过这只是 5 年内的短期预测，更长的发展趋势还需要看 WebAssembly 生态其他的基础设施和编程语言发展状态。

尽管目前 WebAssembly 发展喜人，但百废待兴仍有许多工作要做。我们希望大家更多的是参与到 WebAssembly 建设中去，而不是仅仅作为围观者。作为凹语言作者，我们希望在 2023 年真正解决语言的可用性和易用性的问题，让 WebAssembly 应用构建更加简单。

WebAssembly 作为一个新兴的赛道，作为一个基础设施必将带来更大的生态洗牌，这是一个值得关注和投入的方向，让我们携手共建 WASM 原生时代。

作者简介：

柴树杉，KusionStack 项目开源负责人，凹语言作者。国内最早一批 WebAssembly 技术爱好者，在 2016 年在公司实践 Emscripten 技术，在 WebAssembly 1.0 草案诞生之初出版了《WebAssembly 标准入门》，并发起了面向 WebAssemlby 的凹语言项目。同时也是 Go 语言爱好者，组织翻译了《Go 语言圣经》、出版了《Go 语言高级编程》《Go 语言定制指南》等 Go 畅销图书。

《2022-2023 中国开发者大调查》重磅启动，欢迎扫描下方二维码，参与问卷调研，更有 iPad 等精美大礼等你拿！

☞两万字长文，史上最全 C++ 年度总结！
☞在 MacOS 上运行 Docker 太慢！
☞为了忘却的纪念——2022 Linux 内核十大技术革新功能 | 年终盘点