WebAssembly 会取代 Docker 吗？

导读：

在近日 KubeCon + CloudNativeCon 大会期间，其中一个挺有意思的话题吸引了众人的关注，那便是，由于其独特的设计，WebAssembly（也称为 Wasm）在许多场景下是否可以取代 Docker。

过度关注 WebAssembly 的这个方面其实并没有真正抓住重点，因为更重要的在于 WebAssembly 可以支持哪些具体的业务，本文从会议议程和概念两处详细解释一番。

任何一门新兴编程语言，或者更宽泛地来讲一项新的技术，真正能够考验 WebAssembly  （也称 Wasm，后文中我们可能会混合着写）价值所在的正是它的商业用途。

看起来 WebAssembly  在简易性、可移植性和安全性方面的优势，使其至少可以作为一个弥补 Docker 短板的优秀替补，特别是针对边缘计算和分布式应用程序。

WebAssembly 可用于融合 JavaScript、C++ 和 Rust，加上 HTML 和 CSS 代码，以一个二进制的格式集成到单一的运行时（Run time）里，该二进制格式可以直接在 CPU 的机器层面运行。

它可用于支持 Web 应用程序并且可以扩展到在 CPU 上运行的任何边缘环境及云原生平台，包括服务网格和边缘 Kubernetes 的支持。

在 2019 年万维网联盟（W3C）将其定义为一项 Web 标准之前，WebAssembly  实际上已经存在有一段时间了，自那以后，WebAssembly  成为了继 HTML、CSS 和 JavaScript 之后的第四项 Web 标准。

Adobe 软件工程师 Colin Murphy 在他的演讲中详细介绍了 Adobe 的 CDN 边缘计算以及 Wasm/WASI 平台，还有一些眼下及以后的 Adobe 应用。为了提高业务效能，Murphy 提到 Wasm 如何能成为 Docker 的潜在继任者。

Murphy 说，他只是“环顾四周，然后看看谁会是 Docker 和 Kubernetes 的继任者”，因此当我讲到 WebAssembly 时，我开始说，“好吧，我能应用到一个实际的线上微服务吗，然后我可以使用 WebAssembly 将它部署到边缘服务器的客户端上吗？”，继而他发现自己的预感是对的。

什么是 Docker 容器

Docker 是一种将程序及其依赖项包装到单个包中然后执行应用程序的技术。

Docker Compose提供了一种捆绑应用程序的方法。Kubernetes平台用于在生产集群中执行 Docker 应用程序，其中资源可以分布在多个服务器或虚拟机上。有时我们会谈论 OCI 容器和 OCI 镜像，它们与 Docker 容器和镜像相同。（Open Container Initiative ( OCI ) 是负责编写 Docker 运行时使用的规范的标准机构。）

实际上，Docker 映像是文件系统的一组快照。这些快照分层在一起形成一个单一的环境，（对于应用程序）看起来是一个完整的操作系统。例如要为Web 应用程序创建一个 Docker 镜像，我们会从像Alpine Linux这样的轻量级 Linux 发行版的基本快照开始，然后添加我们自己的 Web 应用程序的支持程序、文件和实用程序。最后我们将添加自己的应用程序，这些都将捆绑为单个 Docker 镜像。

可以使用 Linux 系统创建，当然也可以创建 Windows 的 Docker 镜像。

如果我们执行这个应用程序，容器运行时会按顺序解压缩这些层中的每一层——Linux 发行版、支持文件，然后是我们的应用程序。

使用Linux内核的核心技术，将资源全部解包到一个与宿主文件系统隔离的隔离文件系统中，然后内核会执行我们的程序，就好像这个隔离文件系统是程序的根文件系统一样。

应该记住 Docker 设置的一些特性：

• Docker 镜像是一个完整的文件系统；

• 操作系统很重要：有 Linux 镜像和 Windows 镜像。没有通用镜像；

• 将镜像编译为正确的系统架构也很重要。运行 Docker 的 Raspberry Pi 只能执行为 ARM 处理器编译的 Linux 镜像；

• 对于应用程序，无需专门为 Docker 重写或编译应用程序，但必须针对将运行的主机操作系统和架构进行编译；

• Docker 镜像比虚拟机镜像更轻。当它们被执行时，Docker 容器往往需要比虚拟机更少的系统资源。但它们仍然可以很大。25M 被认为偏小，而许多企业级 Docker 镜像通常是 2G 或更大。

什么是 WebAssembly ？

WebAssembly 是已编译的应用程序。如果我们要将Go、C或Rust应用程序编译为其本机格式，这将得到一个可以执行的二进制文件。

但是我们可以将任何这些语言的程序直接编译到 WebAssembly 中。到那时，我们将得到一个可以在 WebAssembly 运行时执行的二进制文件（如wasmtime、wamr或wagi）。

与 Docker 不同，Wasm 模块不附带预打包的文件系统或其他低级操作系统原语。相反，文件、目录、环境变量、时钟和其他系统资源可以在启动期间直接附加到 WebAssembly 模块。在某种程度上，WebAssembly 系统设施的功能类似于 Kubernetes 的 pod 系统，其中文件系统和环境变量在启动时绑定到容器。但是，对于 WebAssembly，这是WebAssembly 系统接口 (WASI)的核心功能，它是 WebAssembly 标准之一。它是运行时的一部分，而不是更大的编排系统的一部分。

由于 WebAssembly 格式与平台无关，因此可以编译一个二进制文件，然后在各种操作系统和架构上执行。与 Docker 镜像不同，它不仅限于 Windows 和 Linux。WebAssembly 二进制文件可在所有主要操作系统以及许多 RTOS 和嵌入式操作系统上运行。它们也可以在 Intel、ARM 和其他处理器架构上运行。因为 WebAssembly 让运行时知道如何处理文件、环境变量等，所以二进制格式不需要特定于平台的信息。

定义系统交互的 WASI 规范还不完整。正因为如此，许多现有的应用程序不能简单地编译为 WebAssembly。例如，现在还没有办法在 WebAssembly 中启动网络服务器。套接字规范仍在开发中。虽然像 Fermyon 平台这样的工具提供了一种方便的方式来编写微服务和其他联网的 WebAssembly 应用程序，但这需要编写新代码。

出于这个原因，Docker 容器将继续作为运行现有服务（如数据库和消息队列）的一种方式蓬勃发展。但我们觉得WebAssembly带来的新微服务架构将吸引新的开发，因为它更简单、更快且更易于维护。

使用 Wasm 规避漏洞

举个例子，Docker 相关的最主要问题之一便是出现 CVE 级别漏洞的潜在可能性。“有时候，在一个 Docker 容器里，同一个缺陷可能会爆出来好几个 CVE 漏洞。使用 WebAssembly 的话，你没有任何第三方的东西。只需要把它看作是一个二进制文件”，Morphy 在一个播客采访中这样说道。“不过，当然了，这样总归还是会有安全问题。只不过，你不必带上一个操作系统的所有其余部分，也不必装作把它看成是一个完整的操作系统，因为它确实就是自己的单元”，这一说法有助于让 Wasm 变得更令人信服。

Morphy 说，也不必指望 WebAssembly 会完全取代 Docker。

“这个世界仍然会有大型计算机，仍然会有宿主机操作系统，仍然会有跑着非常特殊的业务案例的虚拟机，并且它们还将被继续沿用下去。但是 WebAssembly 也有一些非常好的使用场景，特别是在 5G 汽车的边缘环境，以及所有物联网与世界及边缘环境交界的这类应用程序，在这些地方你将无法再带上 Docker。”

Docker 公司的产品负责人 Jake Levirne 在一封邮件的回复中说道，WebAssembly 是否有可能在某天最终完全取代 Docker 的这一问题首先是不成立的。Levirne 说，这个问题并没有正确解构开发者市场的运作方式，因为 WebAssembly 本质上是一项技术，它并不是要去替代 Docker 这个产品。

“WebAssembly 可以作为 Docker 的补充 —— 无论开发者如何选型其应用程序的架构和实现部分，Docker 都将在这里支持他们的开发体验”，Levirne 说。

Levirne 说，借助 Docker 的开发、测试及部署工具链，我们可以更轻松地去维护一套应用程序交付的可重现式流水线，无论应用程序采用了何种架构。此外，数百万个预构建好的 Docker 镜像，包括数以千计的官方的或是经过验证的镜像，提供了“一套核心服务的骨干（例如数据存储、缓存、搜索、框架等）”，它们可以和 WebAssembly 模块配套使用。

“随着时间的推移，容器运行时和注册表将会扩展到囊括原生的 WebAssembly 模块支持。事实上，这在今天已经发生了，”Levirne 说。

两者并非零和游戏

Docker 有着一些真正的优势：现有应用程序可以在Docker容器中原封不动地运行。依赖于文件系统的大量 IO 并需要对文件系统进行高度控制的程序可能会发现容器比更严格的 WebAssembly 安全沙箱更友好。最重要的是，需要访问Socket层的服务器将在容器世界中更加蓬勃发展。

但在编写微服务、Web 应用程序、事件处理程序和机器学习方面，我们完全有理由相信 WebAssembly 将开辟新的发展途径。开发人员将不再需要从定义他们的 Web 服务器开始。他们将不再负责配置 SSL 或管理线程池或委派系统资源。由于启动和关闭时间极快，WebAssembly 模块可以按需运行，与维护长时间运行的服务器相比，这既便宜又容易。

即便 WebAssembly 可以替代 Docker，但由于 Docker 有自己的生态，并且与 WebAssembly 处于不同的抽象级别，这需要时间。

WebAsembly 将在一些需要高性能和轻量级的领域看到广泛的应用，包括微服务、JAMStack 和边缘计算等。

作者：场长

参考：

https://www.fermyon.com/blog/webassembly-vs-containers

相关阅读：