先谈谈虚拟化吧！

为什么要有虚拟化？物理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的虚拟化，因此基于容器的虚拟化是一种“更轻”的虚拟化方式，同时也具有很好的性能。

为了解决硬件性能和过剩和软件冲突，**「硬件虚拟化」**的普及就很自然而然的出现。对于 Guest OS 和上面的应用程序来说，这台虚拟机和普通物理计算机是完全一样没有任何区别的——除了性能可能差一点。全球第一人气的 VMware Workstation 就是这么一个软件，Oracle 的 VirtualBox 以及 Microsoft 的 Virtual PC 都是。这类软件英语有一个专用的单词是 Hypervisor（虚拟机管理程序）。

虚拟机的优点：

1. 可以把资源分配到不同的虚拟机，达到硬件资源的最大化利用；
2. 相比直接在物理机上部署应用，虚拟机更容易扩展应用；
3. 云服务：通过虚拟机虚拟出不同的物理资源，可以快速搭建云服务。

虚拟机的缺点：

1. Guest OS 通常会占用不少硬件资源。
2. Hypervisor会对硬件的性能在一定程度上受其影响。

为了解决这个问题，容器技术发展了起来，她是应用程序级别的虚拟化技术。和虚拟机相比，容器有以下优点：

1. 更快速的启动时间：没有虚拟机硬件的初始化，没有 Guest OS 的启动过程，可以节约很多启动时间，这就是容器的“开箱即用”；
2. 更高效的利用系统资源：没有运行 Guest OS 所需的内存开销，无需为虚拟机预留运行内存，无需安装、运行 App 不需要的运行库/操作系统服务，内存占用、存储空间占用都小的多。相同配置的服务器，如果运行虚拟机能运行十多台的，通常可以运行上百个容器毫无压力。
3. 一致的运行环境：Docker 的镜像提供了除内核外完整的运行时环境，确保了应用运行环境一致性，从而不会再出现「这段代码在我机器上没问题啊」 这类问题。
4. 持续交付和部署：使用 Docker 可以通过定制应用镜像来实现持续集成、持续交付、部署。

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 是一个新的技术体系而非单一技术，它涉及到编程语言、编译器、虚拟机、工具链 (LLVM, Binaryen 等)、操作系统等相关的多个技术领域。

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

• 加速基于浏览器的应用运行速度，来在一定程度上替代 JavaScript。
• 作为应用沙盒环境（Sandbox）嵌入到应用程序中，为宿主环境（Host）提供一定的安全保障。
• 提供一种插件系统的实现，为产品最终用户提供一定的扩展能力。
• 将不同的编程语言编译成 WASM 来提供它们之间的互操作的可能。

一个引擎如何驱动一段程序运行，并得到结果呢？

1. 第一，我们需要将程序文件加载到内存中，并解析符号，将其中的符号转化成具体的、可访问的内存地址。这一步需要一个加载器和一个链接器；
2. 第二，我们需要执行目标程序，完成其中的每一条指令。如果是 JavaScript 这类脚本程序，我们还需要一个编译组件，将程序文本编译为指令序列。面对指令序列，引擎可以解释执行，也可以进一步编译为物理机器的可执行指令后执行。这一步需要一个能够解释或者编译执行的执行器；
3. 第三，目标程序可能是单线程执行，也可能是并发执行，为了支持并发，要求存在一种调度机制来管理线程。这一步需要一个线程调度器；
4. 第四，一般的程序总是会要求动态内存的分配，用于存储动态数据，那么就要有组件负责分配内存。考虑到内存资源的有限性，不能无限制增长，那么就要有组件负责回收内存。这一步需要一个内存管理器；
5. 最后，目标程序可能要求获得各种外部资源，如访问文件系统、监听网络端口等，引擎必须提供访问这些资源的通道。这一步则需要语言扩展或者外部访问接口。

wasmtime 是非盈利组织——字节码联盟（Bytecode Alliance）旗下的 WebAssembly 引擎，使用 Rust 语言编写开发，是一种高性能编译型 wasm 引擎。

wasmtime 对于 WebAssembly 相关标准支持的完整度非常高。它支持了标准的 WASI，实现了标准的 wasm c-api，并紧密跟踪 WebAssembly 核心特性。

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 是一款基于解释器执行的轻量级 WebAssembly 引擎，使用 C 语言编写开发，wasm3 最大特点就是依靠纯解释器执行所有的 WebAssembly 指令，没有引入 JIT/AOT 编译。根据 Benchmark 数据，自 wasm3 出现在社区并逐渐成熟之后，在相当一段长的时间内，wasm3 都是运行速度最快的解释型引擎。

由于是纯解释执行， wasm3 可以在多系统等设备上运行。而这一点是其它纯编译型引擎无法做到的，这也赋予了它独特的跨平台优势。再考虑到它的轻量特点——移动端二进制产物体积不到 70 KB，作为移动端引擎，wasm3 可谓表现优异。

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 年度完成了行之有效的优化。

基于OneOS，我们希望寻找一个创新的项目进行开发验证，基于此，从虚拟化和安全的角度出发，我们认为WAMR符合这些条件，和传统的虚拟化技术相类比，我们认为她就是物联网下的Docker。它的特性在不同环境下可以带来各种价值，下面简单列举一二：

1. 安全运行第三方代码：这个功能在云端或者边缘计算中非常有意义，也是现代容器技术如 Docker 的核心价值之一。在移动设备、物联网设备、智能小家电以及可信运行环境上对这样的功能也有非常强烈的需求。
2. 跨平台与环境的应用：考虑到 WebAssembly 是由 W3C 定义的标准化字节文件格式，当某些产品需要提供类似浏览器方式来装载第三方模块时，使用 WebAssembly 作为媒介格式是一个非常有吸引力的方案。假设你有一个很好的图像识别算法，你可以把你的算法以 WASM 模块的方式发布。其他人通过集成 WAMR 这样的引擎就可以在不同架构、不同平台、不同环境调用这个算法，比如在云端容器、可信执行环节（TEE）、物联网设备上都可以调用。
3. 超轻量级：资源消耗控制方面，WAMR 运行引擎的二进制文件在 WASM 解释器模式下只有 85KB，在 AoT 模式只有 50KB。16KB 内存就可以跑起来一个 WASM 小程序。
4. 高性能：WAMR 提供了经典（classic）和快速（fast）两个解释器版本，相比常规的 Java 和 JS 解释器具有更高的速度。AoT 和 JIT 模式通过 LLVM 编译框架把 WASM 生成目标平台的机器指令，能够达到接近 GCC 编译的速度。
5. 动态模块加载：这个功能在小设备上尤其有用，过去固件必须统一编译、统一更新，如今通过固件中的 WASM 运行引擎，可以动态加载和执行 WASM 模块。
6. 多语言支持:通过将 Wasm 字节码作为多种编程语言的中间媒介，嵌入式设备使用 Wasm 虚拟机来执行字节码，进而完成对应高级编程语言所指定的任务。通过这种方式，我们既可以利用 Wasm 的高执行效率，又不会失去可以使用高级语言的灵活性。