云原生的下一步，或从WebAssembly在边缘取代Dock

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