WASM能否取代Docker？

云计算、微服务计算、无服务器计算、可扩展计算、可负担计算等等，这一切主要靠一项杰出的技术——Linux容器（LXC）来实现。

Linux容器（LXC）提供了操作系统级的虚拟化沙箱。简而言之，容器允许在一台主机上运行多个隔离的Linux系统。利用Linux内核的某些特征，将共享资源（内存、CPU、文件系统）划分为称为“命名空间”的隔离级别。容器直接在物理硬件上运行，没有仿真，并且资源消耗低（除了设置命名空间的一点初始化之外）。目前使用Linux容器最流行的工具是Docker。Linux容器与虚拟机不同，在虚拟机中，虚拟机管理软件（VirtualBox、VMware ESXi等）模拟物理硬件，虚拟机在该模拟环境中运行。

LXC一直是云计算开发的关键，但是一个新的玩家（我之前在本周刊谈到过）已经进入这个游戏。是的，我指的就是WebAssembly（WASM）。我想我已经多次复制粘贴过WASM的定义，但为了清楚起见，我觉得值得再次阐述一下：“WebAssembly是一种新的二进制格式的开放标准。从设计上看，它是内存安全的、可移植的，并以接近原生的性能运行。其他语言的代码可以交叉编译成WebAssembly。目前，对Rust、C/C++和AssemblyScript（一种为WebAssembly构建的新语言，针对TypeScript的子集进行编译）提供了一流的支持。许多其他编译器已经在开发中。”

众所周知，WASM最初是为浏览器设计的，它是一种在浏览器中取代Javascript来进行计算密集型应用的方式，但是想象一下，有一种交叉编译的二进制格式，其可以提供一种快速、可扩展且安全的方式在所有机器上运行相同的代码，这个想法是相当吸引人的。这就是WASI（WebAssembly系统接口）诞生的原因（可参见2019年的公告）。WASI是一项新的标准，它将WebAssembly的执行扩展到操作系统。它引入了新的抽象层次，使WASM二进制文件可以“编译一次，就能在任何地方运行”，而与底层平台无关。这就是去年让我对WASM感到兴奋的原因，也是引发我在本周刊中发表这篇文章的原因。

开端

然而，前几天我在开发一个小型的Rust微服务，在部署的那一刻，我开始怀疑：“等一下，在这里用WASM也许会很方便”。具体来说，我正在开发的是一个简单的服务器，该服务器可以监听一组webhooks，并根据所触发的webhook及其具体内容触发数据库和其他服务中的动作。它是一个无状态的微服务，我希望它尽可能的轻量级（因此，选用了Rust）。当我在对服务进行Docker化时，我意识到：“为什么不能将我的Rust微服务编译成WASM，并像无服务器功能一样在我的基础架构上按原样运行它？”就在那时，我开始研究WASM在无服务器环境中的使用。显然，很多人之前已经尝试过使用AWS Lambdas和Azure Functions，但我讨厌供应商锁定。我已经使用Kubernetes来管理我的部署（因此，对微服务进行Docker化），为什么我不能在没有附加虚拟化的情况下运行原始WASM二进制文件，就像在Kubernetes上运行Docker容器一样。这将允许LXC和WASM负载共存于我的Kubernetes集群中，使我能够在Kubernetes上部署轻量级WASM（由于WASM二进制文件小，唤醒速度快）功能和应用，并在我的基础架构中融合容器化和无服务器的方法。

在云中使用WASM不仅意味着频繁睡眠和唤醒的轻量级进程的快速启动时间、接近原生代码的性能以及更轻量的二进制文件（这也是其开发的一些初衷），而且还意味着通过设计具有一种沙箱式运行环境。WASM安全模型具有两个重要目标：“（1）、保护用户免受错误或恶意模块的影响；（2）、在（1）的约束下，为开发者提供开发安全应用的有用原语和缓解措施。”这是云安全工程师多年来一直试图在Docker中实现的目标。

Docker与WASM的比较

深入研究后，我发现并不是只有我一个人看到了WASM在云计算中的潜力，就连Docker的创始人所罗门·海克斯（Solomon Hykes）也已经意识到WASM和WASI的结合对云环境的影响：

（tweet）“如果在2008年已经有了 WASM + WASI，我们根本不需要创建 Docker。WASM 就是这么重要。服务器端的 Webassembly 是计算的未来。标准化的系统接口是缺失的环节。让我们希望WASI能够胜任这项任务!”

我强烈推荐大家关注上述推特的回复，可以找到亮点，比如：

（tweet）“那么WASM会取代Docker吗？不会，但是可以想象一下未来Docker并排运行linux容器、windows容器和WASM容器的情景。随着时间的推移，WASM可能会成为最流行的容器类型。Docker会对它们一视同仁，能够全部运行。”

然后我看到了Microsoft的这篇博文和Krustelet的公告，对我的答复的进一步回答。

“重要的是，WASM在很高的层面上具备两个主要特征，Kubernetes生态系统或许能够利用它的优势：

• 与容器相比，WASM及其运行时可以快速执行并且体积非常小
• WASM在默认情况下不能做任何事情；只有在明确的权限下才能执行。

上述两个特征恰好是我们需要的，这暗示了我们或许可以在受限且对安全性要求很高的环境中（在这些环境中，对于容器而言比较困难）有利地结合使用WASM与Kubernetes。”

仅通过LXC，容器的执行还是会受限于底层的体系结构，比如，你试过在Windows在运行Docker嘛？我懂你的困难。但是通过WASM我们有了一个全新的通路，使得我们可以在任何体系上运行虚拟的WASM环境，甚至在虚拟化或容器技术都不支持的架构上（其实浏览器就是这种体系）。我不知道你如何看待这个问题，但是随着我越来越深入的阅读和学习WASM，我就愈发对这个技术感到兴奋。当然我可能也有自己的偏见，无所谓啦。

咱们下周再继续聊！