WebAssembly不会取代Docker

原创 Andy AI大模型实验室

最近有很多关于WebAssembly最终是否会取代Docker的讨论。而讨论的核心，往往集中在容器具备哪些优势特性，比如可移植性、资源节约或者其他属性之类的。按照支持者们的吹捧，容器终有一天会彻底取代虚拟机，但至少在当下，容器还没那牛到那个程度。

Fermyon Technologies公司CEO Matt Butcher告诉The New Stack，“遥想2014年，当容器第一次引起人们注意时，所有的讨论都是关于容器能否取代虚拟机。但经过多年实践，我们意识这两种技术其实是相互补充、而非相互替代。”

虽然关于Docker和Wasm如何互补的讨论也不少，但这种互补性恐怕不会非常普遍。相反，Docker似乎会坚守住分布式应用这一核心据点，而Wasm则继续攻城掠地、开拓更多新鲜用例，特别是在那些能让Wasm发挥安全优势的特定/极端应用场景之下。

— 1 —

应用交集

Butcher解释道，“如果画一张功能维恩图，那容器和WebAssembly肯定会有交集。在未来几年里，行业会逐渐摸索出如何处理其中一部分交集。但我个人认为，这些交集并不算太大，而其余非交集部分将揭示出这两种技术的协同发展方向。”

Docker产品负责人Jake Levirne则在采访邮件中表示，目前的交集用例已经不算少了，但他坚持认为重点根本就不在于Wasm能否有朝一日取代Docker容器，二者融合才是大势所趋。

在Levirne看来，基于Docker的开发、测试和部署工具链之所以大受欢迎，依靠的就是轻松、易维护、可重现的应用程序交付管道，且不受具体应用程序架构的影响。他解释道，“如今我们已经面对数百万个预构建Docker镜像，其中包括数千个官方/经过验证的镜像，足以作为数据存储、缓存、搜索和框架等核心服务主干，与Wasm模块配合使用。而随着时间推移，容器运行时和注册表也将扩展并纳入对原生Wasm模块的支持。实际上，这一切目前正在悄然发生。”

— 2 —

优势与不足

跟Docker容器一样，Wasm在诞生之初就拥有着确切且自适应的计算结构。它能够适应多种不同编程语言，除了常见的HTML和CSS之外，它还能将JavaScript（JS）、C++和Rust集成至单一运行时平台之内，并以二进制格式执行函数。

Wasm既可用于支持Web应用程序，也能扩展至CPU上运行的各类边缘环境/云原生平台，包括服务网格和边缘Kubernetes等场景。另外，Wasm的历史也不算短了，并于2019年被万维网联盟（W3C）指定为Web标准，成为继HTML、CSS和JavaScript之后的第四项Web标准。

而之所以目前的竞争用例间还没出现大量交集，主要是因为Docker容器，特别是容器自身的结构和功能特性。也正是凭借这些特性，让Docker和容器成了DevOps领域的宠儿。如今，除了容器和Wasm之外，市面上还存在裸机、虚拟机、函数即服务（FaaS）等多种不同应用计算架构，未来肯定还会出现更多。

在Levirne看来，这意味着“开发者在选择代码运行方式时，将继续拥有更大的灵活性。容器的优势在于提供丰富的应用执行能力，允许这些应用程序随意使用当前Linux提供的全部开源和商业库、包及工具，同时又提供了相对轻量化的隔离机制。相比之下，Wasm的隔离方法更轻量化，但却只适用于特定一部分纯新建应用程序。换句话说，这些应用程序无法依赖以往无数开源项目的既有成果。”

容器技术在这两大应用场景中势头仍然强劲，“相信这种优势至少还能再持续几年。”在Butcher看来，“原因有二：首先，容器仍是对现有应用程序不加修改、直接打包的最佳选项。换言之，任何现有应用程序都能轻松进行打包、分发并以容器形式运行。其次，数据库和持久数据存储天然跟容器更对路。PostgreSQL、MongoDB和Redis等数据服务用例都更适应传统服务器模型，即一个进程启动完成后，会一口气运行数天、数月甚至数年，期间绝不中断。在这两点上，我认为WebAssembly在很长一段时间内还发挥不出自己的独特优势，所以不可能成功压倒Docker。”

但另一方面，Wasm也不乏证明自身价值的舞台。Wasm的价值核心在于面向二进制结构，因此可以直接在CPU层次上运行，并消除容器镜像内包含代码缺陷等潜在风险。

Adobe公司高级软件工程师Colin Murphy在采访中表示，Wasm代表的正是“人们所说的「业务逻辑」，即用应用代码直接构建Web服务产品”。以Adobe为例，他们使用Wasm和WASI帮助用户在Adobe Sign中签署文档，并在Lightroom中编辑图像。但在除此以外的其他场景下，Docker“仍将主宰一切”，例如数据库、代理和只运行NGINX/Apache的Web服务器等。

Murphy还强调，“具体来讲，任何与WASI基于能力的安全模型相冲突的事物，都还是得由Docker来处理。另外，受到安全模型或其他因素的限制，很多遗留应用程序无法被轻松移植至Wasm。”

SingleStore公司首席软件工程师Bailey Hayes表示，使用用户代码扩展系统的方法多种多样，Wasm的独到之处在于提供一种可移植且安全可靠的沙箱，能够以接近原生的速度在进程内运行。

Hayes解释道，“对数据库而言，只有回避其他解决方案的缺点，例如数据重复、网络通信或进程间通信，才能真正实现高性能。正因为如此，我们才选择Wasm来支持SingleStoreDB中的代码引擎。”

另外，安全性也是Wasm的一大主要卖点。Murphy表示，“与Docker相比，Wasm的优势主要体现在安全性、性能、模块化和大小。而且即使是在允许的范围内，Wasm的要求也更严格一些。”

Murphy解释道，与Docker不同，“我们不能在Wasm上简单构建一个巨型应用程序，把它复制到容器里再直接丢掉生产环境运行。这么干也有好处，比如在运行一个堆大小达128 GB的JVM时，这样能防止效率下降。但同时，这样会大大提升应用程序的移植难度。毕竟Wasm本身就是一种语言，虽然很多语言都能被编译为Wasm，但最终会受到Wasm范式的约束。事实证明，已经针对容器化完成了优化，或者说最没必要移植的应用，反而是最易于移植的。而大部分不符合容器原则的应用程序反正处处受限、难以编译。”

— 3 —

展望未来

前文已经提到，Docker容器和Wasm将各自孕育出能充分发挥其特征与优势的独特用例。如果容器真能在几分钟内解决需求，没人会闲到尝试用Wasm工具来启动Kubernetes集群。

Cosmonic公司联合创始人兼CEO Liam Randall认为，随着“人们越来越多为自己的企业或业余项目编写应用程序和业务逻辑，未来Wasm的生命力将会愈发旺盛并得到广泛认可。Wasm更小、能够真正跨平台开发且轻量化程度更高，足以运行在我们在任意位置指定的任意设备之上。而体量更大、成熟度更高的工具则可能会继续以二进制文件或者容器的形式运行——比如说Nginx、Postgres以及Redis，至少从短期来看，把这些东西编译成Wasm似乎也不会产生什么特别的回报。而且对于那些需要针对数据库之类的东西编写应用程序的人来说，容器仍然是种很好的开发工具。Docker加Postgres的组合将在可预见的未来，继续给开发者们带来出色的体验。所以我估计在短期内，Wasm将主要负责应用程序构建，而容器则负责承载各类工具和软件。”