译者 | 布加迪
审校 | 重楼
公平地说，自上世纪70年代以来，我们的系统运行所依赖的操作系统的核心范式没有真正改变，尽管在此期间我们已学到了很多知识。
我们看到了创新，尤其是在用户体验和并发性方面。不过据F5（隶属NGNIX）的高级产品管理总监Liam Crilly声称，感觉我们仍然只是在针对局部最大值进行优化。
他表示：“我们有线程，也有进程，但它们都植根于同一种抽象。”
Crilly认为WebAssembly（Wasm）为软件开发人员提供了一个难得的机会来重新思考操作系统的整体运作方式，我们利用这个机会才是明智之举。
他说：“有了WebAssembly，我们又重新开始了。”
Wasm和创新的扩散
我们之前详细介绍过WebAssembly，但如果您不熟悉它，多介绍一点背景知识可能会对您有所帮助。WebAssembly是一种二进制指令格式，面向非常小的、基于堆栈的虚拟机（实际上是一个非常简陋的计算机）。
由于Wasm基于堆栈，所以运行在其上面的代码很简单，可以高度优化，因而使它速度极快。针对它的字节码可以移植，Wasm二进制文件极小。它们也很安全，除非主机运行时环境允许，否则无法执行任何操作。您可以使用各种高级语言（包括C/ C++、C#、Dart、Go、Kotlin、Rust和Swift）编写注定在Wasm中运行的代码。
Wasm标准最初源自Mozilla，由字节码联盟监管，该联盟是一个类似Eclipse或云原生计算基金会（CNCF）的基金会。Wasm由W3C实现标准化，因此是继HTML、CSS和JavaScript之后的第四大互联网语言。因此，看到所有主流浏览器都支持该技术也就不足为奇了。
此外，Wasm这种浏览器技术拥有颇具吸引力的优点：高效、快速和安全，因而已经在各种其他环境中得到了应用，这包括Cloudflare Workers、Envoy扩展、Fastly的Compute@Edge以及最近的NGINX Unit。作家、技术专家兼Wasm爱好者Kevin Hoffman甚至认为，云才是Wasm真正大放异彩的环境。
然而不可避免的是，随着这项技术得到进一步的采用，在您应该将Wasm虚拟机的功能扩展到什么程度上是个未知数。在社区内，一场正在进行的讨论探讨了这项技术的未来应该是什么样子，以及它应该在多大程度上类似计算机系统的运作方式。
其背后总是有一系列的权衡和取舍需要考虑。当您思考创新在科技行业的扩散时，看起来熟悉的东西通常会被更快地得到采用。
如果您看一下Java，它迅速发展起来的原因之一是它看起来很像C++，习惯于C语言家族的人可以很快上手。正如首席设计师James Gosling所说，Java是“没有枪、刀或棍棒的C++”。
这是有意为之；Gosling在去年的reClojure主题演讲中说：“我希望C程序员看到Java程序后能够理解其中的原理，大多数情况下他们确实理解。”
另一方面，如果一项技术很快被广泛采用，完善起来就会困难得多，正如Gosling承认的那样：“成功变成了一个问题，因为现在外面有数十亿行Java代码。在Java发布后的几年里，很明显我们无法改变会破坏任何人代码的任何承载体。因此，这确实限制了您在完善方面可以做得多疯狂。”
运行时环境就是操作系统
不过眼下，尽管Wasm势头渐猛，但它并没有这些问题。
Crilly谈到F5时说：“当我们考虑将Wasm用于通用计算时，无论是在浏览器中还是在服务器中，它都没有种种累赘和负担。举例说，它并不自带POSIX，而且并不默认知道关于文件的任何信息。”
“这实际上是一种非常令人担忧的抽象，但您越想它，就越意识到这就是在上世纪70年代的办公空间很有用的一种抽象，当时Unix和POSIX在变得成熟。总的来说，我们在存储和抽象方面比以前要复杂得多，所以默认使用文件作为存储抽象有点愚蠢。”
重新考虑操作系统也有巨大的潜在优势。以数据为例，“我们可以摒弃传统的数据构造，将每个原始数据块视为任何操作的真实对象，”Crilly说。
他补充道，这种范式意味着“在插件模块的帮助下，以我们想要的任何格式，将结果推回到我们需要的任何数据存储系统中。所有关于操作系统本质的先入为主的概念都可能消失，剩下运行时环境——这是计算的最基本要素。换句话说，运行时环境就是新的操作系统。”
Wasm组件模型
Wasm的组件模型方案是将这个愿景变为现实的一种方式。它建立在WebAssembly模块之上，WebAssembly模块在2019年成为官方标准。组件模型是一种新的Wasm二进制格式，它本质上是在WebAssembly核心模块周围添加了元数据。因此，在一个组件中可能有多个模块。
组件模型提供了两点：语言可兼容性和可组合性。组件封装标准的WebAssembly模块，您可以使用导入（组件运行所需的内容）和导出（允许从组件调用的内容）与它进行联系。
组件模型基于无共享链接，这意味着它只导入和导出函数和不可变的值，而不是内存内容、表或可变全局值。这有点类似连接不同进程的Unix管道，或连接不同微服务的HTTP API。
采用这种方法可以消除全部潜在的供应链式攻击。此外，使用函数导入跨无共享边界直接调用可以减少无共享架构中因系统调用、上下文切换和额外复制而导致的通信开销。
据Cosmonic（Wasm平台即服务）的首席技术官Bailey Hayes声称，组件模型还消除了Wasm模块的几个摩擦点。首先，那些导入和导出使用更高级的类型，所以现在可以传入字符串之类的东西。
虽然在使用Wasm绑定之前可以做到这一点，但这很麻烦，因此加以简化显然是成功的做法。
同样，缺乏与WebAssembly模块的语言互操作性是造成摩擦的另一个原因。从技术上讲，Wasm字节码实际上是一堆i32s、整数和浮点类型。它能够调用主机提供给它的函数句柄，这使它能够做更多的事情。
组件模型并不改变这方面，但它改变的是API，我们称之为接口类型；现在有了一个接口类型定义，它不仅仅是一堆数字，它创建了所谓的规范ABI。这样一来，就可以把两个组件连接在一起，让它们相互联系。
这也让我们得以使用任何语言生成语言绑定。字符串的Python表示和字符串的Rust表示不一样，所以我们需要一种提升和降低的方式，这是由组件模型定义的。
Hayes认为，Wasm组件模型最终将成为我们新的计算单元。她说：“这下一波计算浪潮将不再专注于Linux类容器的虚拟化，而是取决于我们的业务逻辑的WebAssembly表示。”
她表示，其中的原因是“组件模型为我们提供了一种新的抽象，这是我们以前从未有过的。它将是最终让我们可以打破整个技术生态系统孤岛的技术之一。”
她进一步解释：“您在行业中经常看到的是，‘这是另一个Rust或C++库的Go原生版本’——您在每个语言生态系统中都能看到这种情况。我们实际上只是在重复同样的工作，在我看来，这纯粹浪费人力和时间。”
相比之下，组件模型让技术人员可以“为工作构建最好的组件，拥有最好的API和最快的组件，然后您可以将其用作库，无论您使用哪种语言。我认为这将是一股真正的创新力量。”
她对Wasm抱有高涨的热情，这确实是一项令人兴奋的技术，不过Crilly发出了警告。
他说：“这种方法存在一些挑战。一个挑战是，我们最终是否会扼杀创新，因为如果一个KeyVal必须遵循相同的API，那么如何将自己与另一个KeyVal区分开来？我的另一个担忧是，人们会急于通过组件模型将所有POSIX抽象引入到WebAssembly。”
“我不希望我们梦游般地进入上世纪70年代的操作系统范式。我们可以做得更好，我真的希望开发人员在开始选择WebAssembly这种技术时认真想清楚这一点。”
原文标题：Why WebAssembly Will Disrupt the Operating System，作者：Charles Humble
