作者 | 蔡芳芳
采访嘉宾 | Michael Yuan
过去几年，云计算的边界不断向边缘侧延伸。作为云原生技术事实标准的 Kubernetes+ 容器组合，自然也被很多人考虑部署到边缘侧，以提高边缘应用部署的效率和便利性，降低边缘应用与硬件之间的耦合度。不过 Kubernetes+ 容器组合并非万用良药，对于边缘计算场景来说，它们还是太重了。
边缘设备通常硬件资源有限，没有足够的资源部署运行完整的 Kubernetes。其他问题还有：很多边缘设备基于 ARM 架构，但大部分 Kubernetes 发行版不支持 ARM 架构；边缘设备所处环境复杂，无法保证稳定可靠的网络连接，而 Kubernetes 不支持离线运行，等等。为了解决包含但不限于以上 Kubernetes 在边缘计算场景下的挑战，更好地将 Kubernetes 从云端延伸到边缘，业内已经诞生了多个基于原生 Kubernetes 优化的开源项目，比如华为开源的 KubeEdge、阿里开源的 OpenYurt、腾讯开源的 SuperEdge、Rancher 开源的 K3s 等，并且这四个项目都已经被云原生计算基金会（下文简称 CNCF）接收。
而传统容器方案比如 Docker，问题与 Kubernetes 类似，它还是一个相对重的容器运行时，镜像大小很容易就达到一两百 MB 以上，对于资源不足的硬件——边缘场景有不少内存和磁盘空间小于 1GB 的微型设备，Docker 也不是一个理想的选择。
边缘计算不仅需要更轻量的 Kubernetes，也需要更轻量、更快的容器方案，WebAssembly 就是近几年出现的一个新选择。
2021 年，对 WebAssembly 的兴趣愈发浓厚，WebAssembly 在云原生方向也十分活跃。到目前为止，CNCF 已经正式接收了至少三个 WebAssembly 项目，包括：WasmEdge Runtime，一个云原生 WebAssembly runtime；wasmCloud，一个 WebAssembly 应用程序框架；Krustlet，一个在 Kubernetes pods 中运行 WebAssembly 程序的工具。其中，WasmEdge 和 Kruslet 通过两种不同的方式，做到了让 Kubernetes 集群中的 WebAssembly 工作负载可以与传统容器（例如 containerd、Docker 和 CRI-O）并列运行，用户可以使用与管理 Docker 应用程序完全相同的工具来管理 WebAssembly 应用程序。
而说到 WebAssembly 最初与 Docker、云原生产生关联，就不得不提 Docker 联合创始人 Solomon Hykes 在 2019 年 3 月份发布的一条推文。他在推文中表示：如果 WASM（WebAssembly）和 WASI（WebAssembly System Interface, WASM 系统接口）在 2008 年就已经存在，那就没有必要创建 Docker 了。
这条推文在社区里引起了很大的反响，有赞同者，但更多的是质疑：WebAssembly 这个发源于浏览器的东西，怎么突然就能在服务端取代 Docker 了呢？随后 Solomon 又发布了一条推文解释道：WebAssembly 不会取代 Docker，但是可以想象未来 WebAssembly 应用容器将与 Linux 容器、Windows 容器在 Docker 中并列运行。如今，Solomon 说的未来已经成为现实，只不过他原话中的 Docker 替换成 Kubernetes 更准确。
Crun 是 Kubernetes 社区里最流行的容器运行与管理工具，由红帽软件发起，一开始只支持基于 Linux 的应用容器。但最近 crun 项目已经正式支持 WasmEdge，能同时运行与管理 WasmEdge 容器镜像与 Linux 容器镜像。通过 crun 的底层支持，目前 WebAssembly 已经融入到了整个 Kubernetes 生态中，开发者可以使用 Kubernetes、Containerd、CRIO 、Docker Hub 来管理 WebAssembly 镜像。
那么，WebAssembly 是如何从前端走向后端的？WasmEdge 在其中扮演什么样的角色？未来在庞大的云原生生态中，WebAssembly 又会占据什么样的位置？InfoQ 近日有幸专访了 WasmEdge 项目创始人 Michael Yuan，请他跟我们聊聊他对于 WebAssembly 的思考，以及 WasmEdge 的发展历程和定位。
WebAssembly 从浏览器走向云原生
Michael 有一个虽然可能引发争论但很有意思的理论，他认为，后端的技术每隔十年左右总要重新发明一次轮子。1999-2000 年 Java 给后端带来了革命性的变化，十年后主角换成了 JavaScript，原本 JavaScript 一直是前端语言，但自 Node.js 诞生后越来越多人也在后端使用 JavaScript 了。这背后的逻辑在于，开发者需要一个轻量级且容易理解的技术，但后端类软件每发展到一定阶段之后都会变得相当复杂，这个时候就会有开发者想重造一个复杂度没那么高的新轮子出来，每十年左右就会有一个这样的周期。2019 年正好是一个新十年周期的开始，而 WebAssembly 就是 Michael 认为的这一个十年周期的新轮子，在他看来，WebAssembly 也会从前端转移到后端然后把后端革命掉。
WebAssembly 发源于浏览器端，最初主要设计来改善 JavaScript 的 Native 性能和代码执行效率。2019 年 12 月 5 日，WebAssembly 经过万维网联盟（W3C）推荐，与 HTML、CSS 和 JavaScript 一起，成为了 Web 的第四种语言。
关于 WebAssembly 技术演变过程，可查阅笔者早前策划的文章：
2021 年 7 月，计算机协会编程语言特别兴趣小组将其享有盛誉的编程语言软件奖（Programming Language Software Award）颁给了 WebAssembly，高度肯定了 WebAssembly 作为“自 JavaScript 以来第一种在 Web 浏览器中广泛采用的新语言”的成就。
不过 Michael 认为 WebAssembly 更大的市场在后端。虽然 WebAssembly 在浏览器里确实发挥了重要作用，但没有达到“必要”的程度，“有了最好，但没有也能用”。WebAssembly 在前端完成的最重要也最有意义的一件事情，是在 Google、Apple、Mozilla、微软这样的大厂和 W3C 这样的组织联合推动下，实现了很好的标准化，这是后来的技术很难去跟 WebAssembly 竞争的地方。也正因为已经通过浏览器端做好了标准化，WebAssembly 才有可能从前端走向后端，才可能在后端做更多的事情。
Michael 认为现在 WebAssembly 想要解决的问题，跟它刚诞生时想要解决的问题是一致的。这个核心问题就是要在一个大型应用程序里，给开发者提供一个可以写扩展的机会。一开始是在浏览器里面可以写应用，这就是对浏览器的一种扩展，只是原来只能用 JavaScript 写，现在有了一个新方法，可以用 C++ 写、可以用 Rust 写，然后编译成 WebAssembly 去运行。
而今天的 WebAssembly 应用依然延续着这个想法。比如在边缘计算场景，或者在 SaaS 应用场景，都是有一个操作系统或应用程序，以前这个系统外部开发者是进不去的，如果要安全地运行外部开发者提交的代码，一个方法就是把代码装在 Docker 里运行。但是 Docker 又太重了，有了 WebAssembly 就可以打开一个口子，把任何一个软件都变成平台。这也是目前流行的一个大趋势，即“软件平台化”。
所以 WebAssembly 除了是一种编程语言，也被视作一个轻量级、快速、安全和多语言的函数“容器”，和 Docker 属于不同抽象层次。如何理解？
Michael 表示容器相关技术可以分为三个抽象层次，其中虚拟机是在计算机层面的抽象；应用容器如 Docker 是在操作系统层面的抽象；WebAssembly 则是在操作系统进程层面的抽象，它与 JVM、V8 都属于高级语言虚拟机，抽象程度最高。
在一般操作系统上面能干的事情在 Docker 里面都能干，但 WebAssembly 不是，它展现出来的是一个执行环境，只能执行编译好的字节码应用，不起操作系统的作用。所以它需要的工具链最复杂，但相应地也能带来性能的巨大提升。根据 WasmEdge 团队的测试结果，在冷启动上 WebAssembly 能做到比 Docker 快 100 倍；在执行时间上，WebAssembly 比 Docker 快 10%-50%。在 Docker 只作为执行环境的场景，即把程序写好了放到 Docker 里执行，执行完之后就关闭 Docker，没有用户互动的情况，就是 WebAssembly 能够完全取代 Docker 的一个应用场景。而边缘计算里有大量这样的场景，这也是 WasmEdge 这个开源项目瞄定的目标场景。
借助 WebAssembly 这样的方案，就能在边缘场景跨平台地、轻量级地、快速地用云原生理念和云原生工具去部署应用程序。Michael 表示，Kubernetes+Docker 这套方法在边缘侧推进遇到了很大阻力，而 WebAssembly 是在正确时间出现的一个正确的解决方案。
WasmEdge 的生态定位
最初决定要做一个 WebAssembly 方向的开源项目时，Michael 和团队成员就想好了要做 WebAssembly Runtime。当时市场上已有的 WebAssembly Runtime 都有两个问题。一个问题是都聚焦在浏览器场景，其中一个非常突出的例子是谷歌的 V8。V8 堪称工程奇迹，它是一个非常复杂、工程化程度非常高的软件，内置一个 WebAssembly Runtime。但 V8 是专为谷歌浏览器优化的，它永远不可能把里面的 WebAssembly 单拆出来，而是必须要和 JavaScript 整套绑在一起，导致体积增加了几十倍。但浏览器需要 JavaScript，后端不需要，后端需要的只是 WebAssembly 这块，但 V8 又不会把它单独拿出来。因此这类 Runtime 并不能很好地满足后端的使用需求。另一个问题是，其他的 WebAssembly Runtime 都是标准驱动的，跟随 WebAssembly 标准，在扩展方面做的不太好。
由于一开始团队还不能确定未来具体的应用场景，因此只是想做一个比较轻量级、易扩展、能够针对各种应用场景优化的开源 WebAssembly Runtime。最初在给项目取名字这件事上也比较随意，直接沿用了创业公司的名字 Second State，将开源项目命名为 Second State VM，即 SSVM。直到今年项目被 CNCF 纳入托管之前，由于 CNCF 要求开源项目的名字里不能有公司的商标，团队才开始考虑给项目换个名字。这时候团队对于这个项目的定位已经有了更清晰的规划，就是要将它用在应该使用 Docker 而 Docker 用不起来的地方，即把云原生这套理念和工具应用到边缘计算场景，这也是 WasmEdge 这个名字的由来。
如今业界已经围绕 WebAssembly 构建起了一个非常庞大的生态，Runtime 可以说是整个生态中最底层的基础设施（下图是以 WasmEdge 为例描绘的 WebAssembly 生态图）。其中最有代表性的项目包括 WasmEdge、V8、Wasmtime、WAMR 等，不同 Runtime 各有各的应用场景和优化点。
Runtime 提供了一个运行代码的地方，但如果每行代码都要从头写的话，对于开发者来说太麻烦了，所以开发者一般会使用框架。在 Runtime 之上还会有运行这些框架的应用服务器，这样的应用服务器在 Java 非常常见，比如 WildFly(Jboss)、ColdFusion、Apache Tomcat、Apache TomEES 等等，JavaScript 也有 Node.js 与 Deno 两个应用服务器。WebAssembly 现在已经有了 wasmCloud 与 Suborbital 两家创业公司，未来势必将涌现出更多应用服务器。
Runtime 之下则是各种各样的操作系统和硬件架构，每一个 WebAssembly Runtime 都会支持一些自己认为比较重要的硬件和操作系统的组合。Runtime 的东西向则是编译器和工具链，因为 WebAssembly 是字节码，就需要上游生态的支持，比如要将 Rust 编译成 WebAssembly，就需要 Rust 编译器的支持。由于标准化做得好，目前很多编译器项目和编程语言的编译器针对 WebAssembly 的编译工具链都已经有了很好的支持。
对于当前的 WebAssembly 生态，还有一个很多人会好奇的问题：我们需要这么多 Runtime 吗？
Michael 表示，现在还是需要的，因为还处在一个百花齐放的阶段，最后哪个 Runtime 能赢还不一定。他认为，从长期来看，最终 Runtime 应该会收敛为 2-3 个，从分布式集群的运维角度考虑，对于很多应用场景，特别是像区块链这样的场景，还是需要有多个 Runtime 的。
“其实现在市场已经收敛得差不多了，能够数得上号的 Runtime 基本也就四个：WasmEdge、Wasmtime、Wasmer 和 WAMR（WebAssembly Micro Runtime）。我觉得肯定还会继续淘汰，直到剩下最后的 2-3 个。”
当然还有一个可能性，就是未来所有 Runtime 都把功能做的差不多，大家都趋于标准化了。不过 Michael 表示，虽然有很多标准化的扩展，但不是每个 Runtime 都会选择去做，因为大家有不同的侧重点。还是以 V8 为例，现在很多在后端做的扩展，V8 就不想做，因为这些在浏览器场景没有意义，做了这些除了增加潜在 Bug 以外，没有什么其他好处。
WasmEdge 目前的重点是推动 WebAssembly 更快地整合到后端生态里面，进而往云原生和边缘计算方向走得更远、更快。前不久，团队与 FutureWei 合作为 seL4 和 WasmEdge 构建了一个 WebAssembly 管理代理，使 WebAssembly 字节码应用程序能在 seL4 RTOS 上简单地被部署和执行，这样一来在如自动驾驶汽车、无人机这样的边缘设备上也可以方便地运行应用程序容器。
此外，如本文开头所述，crun 目前已经合并了 WasmEdge 的贡献，在读取容器镜像时能够自动检测它到底是用于 WasmEdge 还是 containerd/Docker，然后启动和管理相应的 runtime/ 容器，这样一来 WebAssembly 就能够无缝融入现有的 K8s 生态。而且开发者对此是无感知的，开发者用 WebAssembly 编写的应用程序编译后推到 Docker Hub 里面，就能用 K8s 生态中的工具直接管理了。
这是 WasmEdge 向边缘云原生走出的第一步，接下来团队会在边缘场景寻找更多用户案例，在得到充分验证之后，再考虑把 WebAssembly 移到数据中心来取代现有的基础设施的可能性。
取代 Docker 的可能性
两年前，WebAssembly 以超乎预料的发展速度闯入大家的视线，一度被视为 Web 新技术浪潮的主角，当时很多人认为 2020 年会是一个 WebAssembly 应用百花齐放的年份。但 2020 年一场突如其来的疫情，让 WebAssembly 在很多方面的发展都放慢了脚步，不过社区并没有停下对新方向的探索和尝试。2021 年，WebAssembly 迎来了 Web 浏览器之外的爆炸性增长，尤其是在服务器端和云原生环境。
Michael 认为，当前 WebAssembly 正处在一个类似 Java 在 2001-2002 年的阶段。后端应用刚刚开始，虽然很多人还是会觉得这个东西可以放到后端有些奇怪，但认真研究之后也能认可这个思路是 make sense 的。大家对于 WebAssembly 的兴趣也非常浓厚，即使不一定有需求，也有很强烈的想法要试试看有什么办法可以把 WebAssembly 用起来。Michael 觉得这是一个非常有意思的阶段，“生态早期就是这样，Rust 语言一开始也是一样。就是有事没事，以前用 C++ 写的，现在用 Rust 重写。社区对这个东西有兴趣，然后大家都在找这个东西能有什么用。”
在他看来，这是一个行业发展的前奏。早期开发者可能不知道自己的应用场景是什么，但他就是要用这个技术。如果行业没有这个过程的话，就不会有人去推动技术向前走，技术其实是起不来的。这也是他看好 WebAssembly 发展的原因之一，但他同时也坦言，WebAssembly 要真正做到应用的爆发、甚至能够挣到钱，还需要一段时间。“就像在 2001-2002 年之后又过了几年，才开始有围绕 Java 的项目赚到钱。”
据 Michael 介绍，自从加入 CNCF 之后，WasmEdge 项目的社区活跃度有了很明显的提升。相较于在 GitHub 上有多少颗 Star，团队更看重有多少外部开发者在参与开源项目的贡献和讨论。目前 WasmEdge 社区中已经有上百个 Second State 公司以外的开发者给项目提交 Issue，贡献代码的开发者也有数十人。这其中既有来自华为、红帽、微软、蚂蚁集团等大厂的开发者，也有来自如 YOMO 这样的创业公司的开发者。
此外，在社区层面的合作上，现在也已经有很多基于 Kubernetes 的产品与 WasmEdge 展开合作，比如 Linkerd、KubeEdge、SuperEdge 等。同样是以将云原生从数据中心延伸到边缘端为目标，KubeEdge、SuperEdge 与 WasmEdge 之间其实能形成很好的互补，如果说 KubeEdge+Docker 是轻量级 + 重量级的解决方案，那么 KubeEdge+WasmEdge 就是轻量级 + 轻量级的解决方案。
在技术演进上，WasmEdge 不是一个标准驱动的项目，这跟同为 WebAssembly Runtime 类型的 Wasmtime 有很大的不同。WasmEdge 更多是一个由应用场景驱动的项目，即需求来自于社区伙伴在使用过程中遇到的问题，由社区来指导项目的技术研发方向，因此对于社区交流和互动也会更加看重。
对于 WebAssembly 在新一年的发展，Michael 做了一个相对乐观的预测。在他看来，WebAssembly 将会在边缘端得到广泛应用，今天在边缘很多想用 Docker 但又用不了的场景，会被 WebAssembly 给吃掉，尤其是在 KubeEdge 这样的框架的加持下。“在边缘端取得成功之后，它就会像农村包围城市，重新进到数据中心里面去。”
对于 WasmEdge，Michael 非常希望它能够是最后成功的 2 个 Runtime 中的一个。“说实话，我觉得很大概率最后会是 Wasmtime 和我们。两个项目各自聚焦不同的方向，Wastime 聚焦于 Fastly 那套和标准化，我们聚焦于满足边缘计算和边缘设备的需求。”他补充表示，WasmEdge 现在是 CNCF 的项目，而不是 Second State 的项目，Second State 只是为项目提供了一些开发者。他希望，更多对 WebAssembly 感兴趣的人能够聚合到 WasmEdge 项目里来，大家一起把这个项目建设好，最终推动 WebAssembly 生态更好的发展，这也是团队决定将项目捐赠给 CNCF 的初衷和期望。“我们第一是希望 WebAssembly 社区能做好，社区做好了之后，才能够把 WasmEdge 做大，WasmEdge 做大，我们才能够有前途，这家公司才会有前途。”
采访嘉宾介绍：
Michael Yuan，毕业于德克萨斯大学奥斯汀分校，获得博士学位，在开发和商业化开源软件方面拥有丰富的经验。Michael 是 JBoss 的早期员工，被 Red Hat 收购之后，作为产品经理见证了世界上第一个成功的开源商业模式。Michael 著有 5 本国际知名出版社出版的技术书籍。2019 年 Michael 发起了 WasmEdge 项目，提供下一代云原生和边缘计算的执行环境。
WasmEdge 项目地址：https://github.com/WasmEdge/WasmEdge
评论前必须登录！
立即登录 注册