了解她的技术
先谈谈虚拟化吧！
为什么要有虚拟化？物理CPU，物理内存和存储，物理网络的硬件能力越来越丰富的情况下，为了高效、灵活的使用资源，以及在使用时的资源隔离，把硬件资源抽象成软件资源，来动态的业务按需分配和使用。
在虚拟化环境下，物理服务器的CPU、内存、硬盘和网卡等硬件资源被虚拟化并受Hypervisor的调度，多个操作系统在Hypervisor的协调下可以共享这些虚拟化后的硬件资源，同时每个操作系统又可以保存彼此的独立性。根据Hypervisor所处层次的不同和Guest OS对硬件资源的不同使用方式，Hypervisor虚拟化被分为两种类型：Bare-metal虚拟化方式（“裸机”虚拟化）和Host OS虚拟化方式(基于操作系统的虚拟化，宿主型虚拟化)。
Host OS类型将Hypervisor虚拟化层安装在传统的操作系统中，虚拟化软件以应用程序进程形式运行在Windows和Linux等主机操作系统中。典型的宿主型Hypervisor有VMware Workstation和VirtualBox。
Bare-metal类型的Hypervisor虚拟化环境中无须完整的Host OS，直接将Hypervisor部署在裸机上并将裸机服务器的硬件资源虚拟化，Bare-metal类型(裸机)Hypervisor有Microsoft的Hyper-V以及开源的KVM等虚拟化软件。我们常说的虚拟化一般指的是Bare-metal类型。
虚拟化技术又分为全虚拟化（Full Virtualization，FV）、准虚拟化（Para Virtualization，PV）和主机操作系统虚拟化（Host OS Virtualization），其中PV和FV基于Bare-metal类型Hypervisor的虚拟化技术，而主机操作系统虚拟化基于Host OS类型Hypervisor的虚拟化技术。
基于容器的虚拟化技术并不依赖传统的Hypervisor虚拟化引擎，而是在Host OS中配置虚拟服务器环境（Virtual Server Environment，VSE），即无须在Host OS中配置Hypervisor，并且在容器虚拟化中，仅有Guest OS被仿真模拟。由于容器虚拟化技术抛弃了较为复杂的，针对全部硬件资源进行虚拟化的Hypervisor，且是仅针对Guest OS的虚拟化，因此基于容器的虚拟化是一种“更轻”的虚拟化方式，同时也具有很好的性能。
了解她的特点
Docker概述
为了解决硬件性能和过剩和软件冲突，「硬件虚拟化」的普及就很自然而然的出现。对于 Guest OS 和上面的应用程序来说，这台虚拟机和普通物理计算机是完全一样没有任何区别的——除了性能可能差一点。全球第一人气的 VMware Workstation 就是这么一个软件，Oracle 的 VirtualBox 以及 Microsoft 的 Virtual PC 都是。这类软件英语有一个专用的单词是 Hypervisor（虚拟机管理程序）。
虚拟机的优点：
- 可以把资源分配到不同的虚拟机，达到硬件资源的最大化利用；
- 相比直接在物理机上部署应用，虚拟机更容易扩展应用；
- 云服务：通过虚拟机虚拟出不同的物理资源，可以快速搭建云服务。
虚拟机的缺点：
- Guest OS 通常会占用不少硬件资源。
- Hypervisor会对硬件的性能在一定程度上受其影响。
为了解决这个问题，容器技术发展了起来，她是应用程序级别的虚拟化技术。和虚拟机相比，容器有以下优点：
- 更快速的启动时间：没有虚拟机硬件的初始化，没有 Guest OS 的启动过程，可以节约很多启动时间，这就是容器的“开箱即用”；
- 更高效的利用系统资源：没有运行 Guest OS 所需的内存开销，无需为虚拟机预留运行内存，无需安装、运行 App 不需要的运行库/操作系统服务，内存占用、存储空间占用都小的多。相同配置的服务器，如果运行虚拟机能运行十多台的，通常可以运行上百个容器毫无压力。
- 一致的运行环境：Docker 的镜像提供了除内核外完整的运行时环境，确保了应用运行环境一致性，从而不会再出现「这段代码在我机器上没问题啊」 这类问题。
- 持续交付和部署：使用 Docker 可以通过定制应用镜像来实现持续集成、持续交付、部署。
Webassembly概述
Docker的创始人所罗门·海克斯（Solomon Hykes）说过："如果在2008年已经有了 WASM + WASI，我们根本不需要创建 Docker，WASM 就是这么重要。服务器端的 Webassembly 是计算的未来。标准化的系统接口是缺失的环节。让我们希望WASI能够胜任这项任务!"，可见其对WASM的重视和青睐。
WebAssembly 技术源于浏览器，其发展历程可以说是一部浏览器性能优化史。在 Web 前端领域，JavaScript 语言是编写运行在浏览器上的 Web 应用的首选，为了满足应用日益增长的性能需求，针对 JavaScript 语言本身缺陷带来的瓶颈优化，逐步形成了三个阶段性优化产物，他们分别是 asm.js、NaCl/PNaCl 以及 WebAssembly。
随着 WebAssembly 在开发者社区中越来越流行，WebAssembly 的潜在价值从 Web 逐渐开始向其他领域，比如云原生、AI 以及区块链，物联网等；2019 年 12 月，Bytecode Alliance 字节码联盟宣布正式成立，联盟旨在通过协作的方式，来共同实现 WebAssembly 及 WASI 相关标准，并通过提出新标准的方式来共同打造 WebAssembly 在浏览器之外的未来生态。
英特尔的 WebAssembly Micro Runtime（WAMR）和 Mozilla 主导的 WASMTIME 成为转入字节码联盟的第一批核心开源项目。字节码联盟的目标是基于 WebAssembly 和 WebAssembly System Interface（WASI）等标准创建一个安全、高效和模块化的新运行引擎（Runtime）环境和语言工具链，同时推广让尽可能多的平台和设备使用它们。
WASM应用场景
WebAssembly 是一个新的技术体系而非单一技术，它涉及到编程语言、编译器、虚拟机、工具链 (LLVM, Binaryen 等)、操作系统等相关的多个技术领域。
WASM 的名称的体现了它在最初的设计中人们对它的希望：能够在 Web 环境中快速地运行。目前，WASM 已经能够在包括浏览器在内的很多不同的环境中运行。这些场景包括：云原生场景、移动设备、物联网、区块链等多种不同的场景。在这些场景中，大家使用 WASM 的主要目标包括，但是不限于如下几个方面：
- 加速基于浏览器的应用运行速度，来在一定程度上替代 JavaScript。
- 作为应用沙盒环境（Sandbox）嵌入到应用程序中，为宿主环境（Host）提供一定的安全保障。
- 提供一种插件系统的实现，为产品最终用户提供一定的扩展能力。
- 将不同的编程语言编译成 WASM 来提供它们之间的互操作的可能。
常见WASM引擎
一个引擎如何驱动一段程序运行，并得到结果呢？
- 第一，我们需要将程序文件加载到内存中，并解析符号，将其中的符号转化成具体的、可访问的内存地址。这一步需要一个加载器和一个链接器；
- 第二，我们需要执行目标程序，完成其中的每一条指令。如果是 JavaScript 这类脚本程序，我们还需要一个编译组件，将程序文本编译为指令序列。面对指令序列，引擎可以解释执行，也可以进一步编译为物理机器的可执行指令后执行。这一步需要一个能够解释或者编译执行的执行器；
- 第三，目标程序可能是单线程执行，也可能是并发执行，为了支持并发，要求存在一种调度机制来管理线程。这一步需要一个线程调度器；
- 第四，一般的程序总是会要求动态内存的分配，用于存储动态数据，那么就要有组件负责分配内存。考虑到内存资源的有限性，不能无限制增长，那么就要有组件负责回收内存。这一步需要一个内存管理器；
- 最后，目标程序可能要求获得各种外部资源，如访问文件系统、监听网络端口等，引擎必须提供访问这些资源的通道。这一步则需要语言扩展或者外部访问接口。
wasmtime
wasmtime 是非盈利组织——字节码联盟（Bytecode Alliance）旗下的 WebAssembly 引擎，使用 Rust 语言编写开发，是一种高性能编译型 wasm 引擎。
wasmtime 对于 WebAssembly 相关标准支持的完整度非常高。它支持了标准的 WASI，实现了标准的 wasm c-api，并紧密跟踪 WebAssembly 核心特性。
WasmEdge
WasmEdge 是一款由 CNCF（Cloud Native Computing Foundation，云原生计算基金会）托管的 WebAssembly 引擎，其命名也在告诉我们：WasmEdge 主要面向边缘计算、云原生和去中心化应用。根据 IEEE 论文数据，WasmEdge 是当时运行性能最高的 WebAssembly 运行时。但根据最新的 2023 wasm runtime benchmark 数据[2]，wasmedge 的性能优势已经有所削弱。
与 wasmtime 一样，WasmEdge 也是一种编译型的 wasm 引擎，可以按照 JIT/AOT 两种模式对 wasm 指令进行编译，并最终执行。不同之处在于，WasmEdge 使用 LLVM 作为编译器后端，利用了 LLVM 出色的优化编译能力。因此，相比于使用 Cranelift 的 wasmtime，WasmEdge 生成的指令更优，执行速度更快。
除了卓越的性能表现之外，WasmEdge 的一个最为显著的特点就是社区提供丰富的扩展能力。比如，在云原生的使用场景中，很多开发者使用 JavaScript 语言开发应用。
wasm3
wasm3 是一款基于解释器执行的轻量级 WebAssembly 引擎，使用 C 语言编写开发，wasm3 最大特点就是依靠纯解释器执行所有的 WebAssembly 指令，没有引入 JIT/AOT 编译。根据 Benchmark 数据，自 wasm3 出现在社区并逐渐成熟之后，在相当一段长的时间内，wasm3 都是运行速度最快的解释型引擎。
由于是纯解释执行， wasm3 可以在多系统等设备上运行。而这一点是其它纯编译型引擎无法做到的，这也赋予了它独特的跨平台优势。再考虑到它的轻量特点——移动端二进制产物体积不到 70 KB，作为移动端引擎，wasm3 可谓表现优异。
WAMR
wasm-micro-runtime 也简称为 WAMR，与 wasmtime 一样是隶属于 Bytecode Alliance 的开源 WebAssembly 引擎项目，适用于嵌入式平台、各类 IoT 设备、智能合约和云原生等场景。名字中的 micro 也正是它的特点之一：WAMR 的二进制产物很轻量，纯 AOT 配置的产物体积只有约 50KB，非常适合资源受限的宿主。
WAMR 同步支持解释与编译两种方式执行 wasm 程序，因此兼有两种执行方式低冷启延迟、高峰值性能的优点。使用编译模式时，宿主可以选择使用 JIT 或 AOT 方式执行目标程序。与 WasmEdge 相同，WAMR 的编译器也基于 LLVM 构建。根据官方数据，JIT 或 AOT 的执行方式可以得到接近原生的速度，表现十分亮眼。而援引最新的 2023 年 wasm runtime 的性能测试数据，wamr 是运行速度最快的引擎。可见，wamr 在 2022 年度完成了行之有效的优化。
差异对比
| 引擎 | 关键特征 |
|---|---|
| wasmtime | 高性能编译 字节码联盟项目 应用于Serverless等场景 |
| wasm3 | 高性能解释器 跨平台, iOS 等平台 通用轻量级引擎 |
| WasmEdge | 在 Docker 中集成 使用 LLVM 编译后执行 社区提供了非常丰富的扩展能力 |
| wasm-micro-runtime | 解释 & 编译两种运行模式 使用 LLVM 作为编译后端 运行速度最快的引擎 适用于 IoT 设备等资源受限的场景 |
期待和她携手
基于OneOS，我们希望寻找一个创新的项目进行开发验证，基于此，从虚拟化和安全的角度出发，我们认为WAMR符合这些条件，和传统的虚拟化技术相类比，我们认为她就是物联网下的Docker。它的特性在不同环境下可以带来各种价值，下面简单列举一二：
- 安全运行第三方代码：这个功能在云端或者边缘计算中非常有意义，也是现代容器技术如 Docker 的核心价值之一。在移动设备、物联网设备、智能小家电以及可信运行环境上对这样的功能也有非常强烈的需求。
- 跨平台与环境的应用：考虑到 WebAssembly 是由 W3C 定义的标准化字节文件格式，当某些产品需要提供类似浏览器方式来装载第三方模块时，使用 WebAssembly 作为媒介格式是一个非常有吸引力的方案。假设你有一个很好的图像识别算法，你可以把你的算法以 WASM 模块的方式发布。其他人通过集成 WAMR 这样的引擎就可以在不同架构、不同平台、不同环境调用这个算法，比如在云端容器、可信执行环节（TEE）、物联网设备上都可以调用。
- 超轻量级：资源消耗控制方面，WAMR 运行引擎的二进制文件在 WASM 解释器模式下只有 85KB，在 AoT 模式只有 50KB。16KB 内存就可以跑起来一个 WASM 小程序。
- 高性能：WAMR 提供了经典（classic）和快速（fast）两个解释器版本，相比常规的 Java 和 JS 解释器具有更高的速度。AoT 和 JIT 模式通过 LLVM 编译框架把 WASM 生成目标平台的机器指令，能够达到接近 GCC 编译的速度。
- 动态模块加载：这个功能在小设备上尤其有用，过去固件必须统一编译、统一更新，如今通过固件中的 WASM 运行引擎，可以动态加载和执行 WASM 模块。
- 多语言支持:通过将 Wasm 字节码作为多种编程语言的中间媒介，嵌入式设备使用 Wasm 虚拟机来执行字节码，进而完成对应高级编程语言所指定的任务。通过这种方式，我们既可以利用 Wasm 的高执行效率，又不会失去可以使用高级语言的灵活性。