CNCF landscape 由 CNCF 委托 Second State 制作。本文为译文,译者:Miley Fu, Vivian Hu ,原文作者:Chris Aniszczyk、Vivian Hu 、Michael Yuan,原文链接:https://www.cncf.io/blog/2023/09/06/introducing-the-wasm-landscape/
“容器已成为新常态,WebAssembly 是未来。”
—— CNCF 2022 年年度调查主要发现。
WebAssembly(Wasm) 最初是为了在网页浏览器中运行编译的 C/C++ 代码而创建的一个安全沙箱,但它正在服务器端获得越来越多的关注和发展势头。在云端,Wasm 提供了一个轻量、快速、安全、跨语言、跨平台的应用程序运行时,可用于各种由用户提交的工作负载。它正在快速成为云原生技术栈的一个关键部分。
随着 Wasm 在云原生项目、产品和服务中的采用,CNCF 与 Wasm 社区合作创建了一个Wasm 生态全景图,以更好地理解 Wasm 生态的范围。正如最初的云原生全景图帮助勾画了围绕云原生技术的大量生态,我们相信随着生态的发展和增长,Wasm 也需要同样的全景图。
Wasm 全景图 第一版在 WasmCon 会议上发布,包括 11 个类别和 120 个项目或产品,代表总经济价值 594亿美元。 Wasm 全景图分为两大领域:Dev(应用程序开发)和 Ops(应用程序部署)。
Wasm 应用程序开发需要自己的编程语言和相关工具生态,例如编译器、框架、库、工具和运行时。
当开发者创建应用程序时,他们从选择一种编程语言开始! Wasm 的特点之一是它能够运行用各种不同编程语言编写的应用程序。然而,这并不意味着所有编程语言都是平等的。
事实上,Wasm 全景图中有 4 类编程语言。
一等公民是可以直接编译为 Wasm 字节码并在 Wasm 运行时运行而无需任何依赖的语言。 C 、 C++ 、 Zig 和 Rust 都属于这一组。他们生产最快和最小的 Wasm 应用程序。
让我们以 Rust 为例。安装 Rust 语言后,你所需要做的就是添加 wasm32-wasi 目标。
托管语言仍然是编译语言。但编译器输出需要“托管运行时”才能正常运行。托管运行时最常见的任务是垃圾收集(或 GC)。
对于 Kotlin 和 Dart 这样的语言,Wasm GC 功能就足够了。 WasmEdge、Wasmtime 和 v8 等领先的 Wasm 运行时最近添加了 Wasm GC 支持。
对于 Go 来说,编译器将必要的运行时二进制文件嵌入到编译后的 Wasm 字节码中。这增加了 Wasm 应用程序的大小,但仍然提供了良好的开发者体验。
对于复杂的托管语言,例如 Java 和 .Net (例如C#),我们需要将它们的托管运行时(例如 JVM)与 Wasm 中的字节码应用程序一起编译和运行。这通常是一种不轻量的方法。
JavaScript、Ruby、PHP 和 Python 等脚本语言也可以在 Wasm 中运行。这里的方法是将脚本语言解释器(通常用 C 编写)编译为 Wasm。然后基于 Wasm 的解释器程序就可以执行脚本了。
例如, VMware Labs 的 **WebAssembly Laungage Runtimes 项目**已将 Python 和 PHP 解释器移植到 Wasm。
WasmEdge QuickJS 项目提供了一个 JavaScript 解释器以及一个支持 JavaScript 中的 node.js API 的 Wasm 库。
最后但并非最不重要的是针对 Wasm 目标进行优化的新一代编译语言。他们仍处于非常早期的阶段。但如果做得好,他们有潜力成为 Wasm 全景图中真正的一等公民。
Moonbit 和 Grain 是该类别中的两个领先示例。它们采用 Go 和 Rust 中的现代语言功能进行设计,并针对高效的 Wasm 编译和执行进行了优化。
Moonbit 虽然还处于早期阶段,但它配备了从动态代码补全到在线 IDE 的一整套工具。
一旦源代码被编译成 Wasm 字节码,你将需要 Wasm 运行时来执行它们。 Wasm 运行时提供了通常与 Wasm 相关的所有功能和优点,例如沙箱安全性、速度和跨平台可移植性。它们位于全景图的中心。
在这个云原生 Wasm 全景图中,我们将重点关注服务器端流行的 Wasm 运行时。我们有**WasmEdge (CNCF 沙箱)、 Wasmtime/lucet 、 Wamr、 WAVM 、Wasmer、** wasm3 、 Lunatic 、 wazero 、 Wasmer和V8 。
Wasm 运行时类似于操作系统。库和框架为应用程序开发者提供了所需的高级且易于使用的组件。
WasmEdge 运行时的独特之处在于它支持超出 Wasm 标准的高级 POSIX API,它允许许多流行的 Rust 和 JS 应用程序框架,例如 tokio、hyper、reqwest、warp、node.js,以及 MySQL / Postgres / Redis / Kafka /ElasticSearch 客户端库,在 WasmEdge 中运行。然而,对于所有其他 Wasm 运行时,应用程序框架需要提供基本功能,例如 HTTP / HTTPS 网络和数据库访问。
在全景图的这部分中,我们涵盖了 Spin、WasmCloud (CNCF 沙箱)、SpiderLightning、 WasmEdge plug-ins、Dapr SDK for WasmEdge、Homestar、Ambient、WASIX、Extism、Timecraft、vscode-wasm 和 WasmEx 。
Wasm 的一个关键特性是跨平台可移植性,这意味着能够跨不同操作系统和 CPU 架构执行相同的字节码应用程序。在 JVM 时代,操作系统仅限于类 Unix 系统(例如Linux)、Windows 和 MacOS。然而,Wasm 可以在边缘和物联网计算中常用的非传统系统上运行。
Docker 和 Linux 容器从来都不是跨平台的。例如,容器镜像必须与主机 CPU 匹配。
随着人工智能工作负载在云数据中心越来越受欢迎,Wasm 越来越多地用作重量级、复杂且缓慢的 Python 堆栈的替代方案。 WASI NN 规范定义了 Wasm 运行时应如何与本机 AI/ML 库(例如 PyTorch 和 TensorFlow)交互,以使用 Rust 等高性能语言进行 AI 推理。
Wasmtime、WasmEdge 和 WAMR 是支持 WASI NN 的 Wasm 运行时。
例如,WasmEdge 运行时支持 OpenVINO 、 Pytorch 、 Tensorflow 、 TensorFlow Lite 和 MMGL/Llama2 作为推理后端,以及 OpenCV 、 ffmpeg 作为预处理器或后处理器。同时也支持 mediapipe、document AI、llama2等多种模型。
Wasm 可以安全地执行用户定义或社区贡献的代码作为软件产品中的嵌入式函数(或插件)。
在 Wasm 全景图的这一部分中,我们展示了选择并集成 Wasm 作为插件机制的软件产品。最长的类别是数据库和数据流应用程序,其中的 Wasm 用于执行用户定义函数(UDF)。
Libsql、OpenGauss 和 Singlestore 等数据库以及 Open Policy Agent、InfinyOn、YoMo、eKuiper 和 Redpanda 等消息队列正在使用 Wasm 来执行 UDF。 Envoy、Istio、APISIX、KubeWarden 和 NGINX 等流量代理正在使用 Wasm 在数据平面中执行自定义逻辑。 OpenFunction 和 Knative 等 FaaS 平台允许将 Wasm 函数嵌入到 Kubernetes Pod 中。
最后,开发者依靠工具将语言、框架、库和运行时拼凑成工作应用程序。工具链的成熟度是衡量整个开发者生态成熟度的重要指标。在 Wasm 全景图,我们介绍了用于构建 Wasm 应用程序的重要工具。
创建 Wasm 应用程序后,下一步是在生产中部署和扩展它。云原生全景图中有大量的工具、框架和服务来管理应用程序部署。其中许多都集成了 Wasm 支持。
Wasm 容器可以通过 Docker、containerd 和 Kubernetes 等现有容器工具进行无缝管理。有两种方法可以将 Wasm 应用程序作为“容器”进行管理。这两种方法都可以让你构建并行运行 Linux 容器和 Wasm 容器的 Kubernetes 集群。
方法#1是在容器管理堆栈的基础上使用 OCI 运行时,例如 crun 和 youki 。 crun 根据镜像的目标操作系统和 CPU 平台检测 OCI 镜像是 wasm 还是 Linux。如果镜像的目标是 wasi/wasm,crun 将绕过 Linux 容器设置过程,只使用 WasmEdge 来运行它。基于crun,我们可以获得整个 Kubernetes 堆栈来运行 Wasm 镜像,包括 CRI-O (CNCF项目)、 containerd(CNCF项目) 、Podman、kind、K8s (CNCF项目)、 OpenYurt (CNCF项目)、 SuperEdge (CNCF项目)、 KubeEdge (CNCF 项目)。
方法#2是使用 containerd-shim(例如 runwasi )在 containerd 中运行 Wasm 应用程序。当 containerd 接收到镜像时,它会检查镜像的目标平台,如果镜像是 wasi/wasm,它会路由到 runwasi 执行,如果镜像是 x86 或 arm,它会路由到 runc。
在 Kubernetes 的基础上,我们还介绍了一些新兴工具来帮助管理生产 Wasm 工作负载。
Kuasar 是另一个支持多种类型沙箱的容器运行时,包括 microVM、Linux 容器、应用程序内核和 WebAssembly 运行时。
Kwasm 是一个 Kubernetes Operator,它为你的 Kubernetes 节点添加了 WebAssembly 支持。它可与基于 Ubuntu/Debian 和 Containerd 的本地和托管云 K8s 发行版配合使用,
container2wasm 是一个容器到 wasm 镜像转换器,可以在 WASM 上运行容器。
如果你不想麻烦地运行自己的服务器和 Kubernetes 集群,那么托管平台是将 Wasm 应用程序部署和扩展为服务的绝佳选择。
基于区块链的智能合约平台是去中心化的云计算网络。你的云应用程序(即智能合约)不是由中心 Operator 运行所有工作负载,而是由网络中的节点执行。由于智能合约不受信任并且必须非常频繁地执行(每台计算机每秒数百次),因此 Wasm 是该应用场景的理想执行引擎。事实上,几乎所有领先的智能合约区块链网络都采用了 Wasm。
调试和可观测性是重要的生产功能,使运维团队能够持续监控应用程序并向开发团队提供有用的反馈。这是 Wasm 全景图中目前有所缺乏的部分。我们预计这个领域会随着 Wasm 越来越多地部署在生产中而生长壮大。
Artifacts repo 是全景图中的重要元素。它们提供集中且始终可用的位置来存储、发现、验证、下载、跟踪多个已发布版本的 Wasm 包。它们不仅是便利的工具,而且对于软件供应链安全也至关重要。
Wasm 全景图的制作离不开社区共同的努力,随着 Wasm 采用的兴起,Wasm 全景图也在快速发展。我们打算随时更新最新进展。然而,我们只有在整个 Wasm 社区的帮助下才能做到这一点。
如果有任何想要添加或更新的内容,请提交 PR!可以参考此 PR添加你的项目名称、logo、网站、GitHub repo 链接和 crunchbase。
|