WebAssembly技术、生态简要分析(上)

WebAssembly技术、生态简要分析(下)

近两年来，WebAssembly相关技术在很多Conf和Summit上成为一个较为热点的讨论话题。对于不是很熟悉这个领域的大部分人的第一感觉里，WebAssembly还是一个浏览器端的技术，但实际上，当前WebAssembly的能力已经大大的延伸到了前端领域之外，甚至开始辐射到云数据中心和边缘计算领域。

什么是WebAssembly呢？

事实上，WebAssembly既不Web也不AssemblyImage。WebAssembly(也简称为WASM)是一个可迁移的字节码(byte code)的执行环境的标准。它的目标是使软件具备安全，高性能(near native performance)，可迁移(portable)和紧凑精简(compact)的能力。它可以在在浏览器中被集成，同时通过现有的WASM runtime，它也可以在浏览器外被解释和执行。

甚至Docker的创始人Solomon也曾发过这样的twitter：

足以可见大家对这种技术的高度关注。

为什么WebAssembly具备安全、高性能、可迁移和精简的优势呢？
1.安全
WebAssembly是一个默认就具备安全能力的平台。它提供了一种基于能力控制的(capabilities-based)沙箱环境。除非在环境启动时显式的指定它的能力，否则沙箱中的应用默认不具备任何例如文件系统访问，网络连接等的权限。这是一种针对于应用程序级别的，细粒度的控制机制(通过nano-processes)。通过这种机制，有效的消除或者减轻了现代应用程序(modern app)部署中的问题，特别是对于那种大量使用了第三方代码的应用(例如在NPM生态中的软件)，可以有效的避免Supply Chain Attack。

Supply Chain Attack的介绍在这篇medium中给出了一个具体实例(如无法访问，可能需要注意科学上网😊)：
文章链接
大体的思想是因为在依赖管理系统中缺乏安全控制能力，导致因为一个应用本身的安全问题传播到了其他依赖于这个应用的软件中。 而对于依赖于很多第三方软件的应用，本身并不能有效鉴别这些第三方软件的合法性、安全性。

关于Capability-Based的思想，主要来源于这篇paper：
链接

2.高性能
WASM高性能的优势主要体现在两个方面：冷启动时间和系统调用时间。
在这篇paper中实验对比了多个公有云平台上WASM相较于Docker容器的性能。
https://arxiv.org/abs/2010.07115

冷启动时间和系统时间相较于容器都是一个数量级的提升。

3.可迁移
WebAssembly的字节码被设计在可以高效执行在多个操作系统和指令集之上。可以在Web端执行也可以在Web之外。
通过一些已有的工具(例如Emscripten), 可以方便的将C/C++或其他语言的代码编译成WASM的字节码。
这种优势无疑是巨大的。在软件工程领域，经过多年的累积，有大量的高质量的使用C/C++等语言编写的，不具备跨平台部署能力的软件。如果可以对这些代码零入侵的编译成WASM的字节码，那么就能以极低的工程成本赋予了这些软件跨平台执行的能力。

3.精简
在传统的虚拟机和容器中，往往需要包含支撑这个运行环境的整个软件栈，包括每个函数调用所依赖的所有操作系统相关的标准库。这使得这个环境变得臃肿。而WASM的运行时环境中，仅仅需要包含一个以.wasm为后缀的WASM字节码文件。这使得它的体积往往仅仅是容器镜像的十分之一。

WebAssembly生态

WebAssembly Community Group起初只是W3C下的一个组织，后续这个W3C WebAssembly CG变成了一个W3C Working Group，主要来制定标准。这个Working Group定义了一个支持所有主流浏览器的MVP平台。
之后Node.js社区发现WASM可以解决Node应用中的使用低级语言编写的native库的管理问题。之前这些native库需要考虑它们在不同Linux，macOS及Windows等多种OS的依赖问题。而现在Node的应用只需要使用一个可以被加载进V8环境中的WASM库，然后通过这种方式把原先应用中的native的库都实时转换成WASM的字节码，就可以运行了。

之后，Google，Microsoft，Mozilla，amazon，Intel，fastly等公司成立了非盈利组织Bytecode Alliance，目标是开发WASM运行环境、语言工具链及制定WASM和WASI的标准。

目前BYTECODE ALLIANCE成员：

在Bytecode Alliance旗下，有三个开源项目，分别是Lucet，wasmtime和WAMR。
wasmtime是在浏览器之外的WASM的运行时，也是Bytecode Alliance主推的运行时。WAMR(WebAssembly Micro Runtime)是一个在IoT，嵌入式设备、边缘端运行的更轻量级运行时。
Lucet是一个早期WASM的编译器和运行时，目前Lucet已经是wasmtime的一部分了。

WASI又是什么呢？

WASI(WebAssembly System Interface)，它是wasmtime的API。它是“a rich set of APIs for interacting with the host environment”(例如操作文件系统、socket和获取随机数、时钟信息的接口)。正是因为有了WASI，被编译生成的WASM字节码才可以在任何支持WASI的平台运行。

目前，在Bytecode Alliance之外，其实也有众多其他的开源WASM运行时。对于这些WASM运行时，也会遵循WASI的全部或部分标准，那它们各自的定位和特点又是如何呢？
有了运行时环境，自然而然的就会联想到管理平台，那目前的WASM的云端及边缘端的管理平台的现状又是如何呢？请期待下篇文章

WebAssembly技术、生态简要分析(下)

请关注公众号 “小明的IT世界”