4.6 KiB
17.8 WebAssembly 与容器
本节介绍 WebAssembly (简写为 Wasm) 以及它为何成为现代容器生态中备受瞩目的前沿技术路线。
什么是 WebAssembly？
WebAssembly (Wasm) 最初是由 W3C 主导的一项为了解决网页中 JavaScript 性能瓶颈而发明的技术标准。它是一种小体积的、加载极快的、提供安全沙盒的高效二进制格式的指令集架构。通过将 C/C++、Rust、Go 等高级语言编译成 .wasm 格式，这些程序可以直接在所有现代的浏览器中以接近原生代码的速度安全地运行。
然而，一项原本用于前端领域的技术，为何如今却与容器云计算生态产生了强烈的化学反应？
因为开源社区很快意识到，Wasm 所具备的核心特性完美契合了云原生后端的诉求。人们制定了诸如 WASI (WebAssembly System Interface) 这样的标准，将其能力从浏览器扩展到了服务器端操作系统上。
Wasm 与容器特性的完美契合
将 Wasm 应用于服务端时，它展现出了一些可能比传统 Linux 容器更为优异的特性：
-
极速的冷启动性能： 传统 Linux 容器虽然比虚拟机轻量很多，但它启动依然需要建立 Namespace 和 Cgroups 以及一整套文件系统，通常需要近百毫秒到几秒。而 Wasm 模块不需要这样庞杂的环境初始化，能够在几毫秒之内完成从加载到执行，这对于无服务器函数（Serverless Functions）而言是巨大的提升。
-
跨平台性 (Write Once, Run Anywhere)： 我们知道 Docker 等容器通常是绑定架构的。如果是 x86_64 平台上打出的镜像，通常无法直接在基于 ARM 的系统（如苹果 M 系列芯片甚至树莓派）上直接运行原生代码，除非使用 QEMU 进行低效转译或者专门构建多架构（Multi-arch）镜像和 manifests。 而 Wasm 二进制本身是平台无关的平台中间语言代码形式！你编译出来的一份
.wasm可执行模块，不用做任何修改，就可以在 x86 的 Linux 服务器、ARM 的边缘设备、甚至是 Windows 和 macOS 上直接通过 Wasm 运行时来驱动和执行。真正做到了“编写一次，到处运行”。 -
天然的安全沙箱机制： Wasm 设计之初就是在不被信任的浏览器沙盒环境中运行未知代码的，因此执行环境非常安全，采用了极好的能力导向安全模型。应用只能访问它被明确授予权限的文件或能力。其默认安全隔离性比起依靠 Namespaces 机制的共享内核的 Linux 容器更加坚固。
-
极小的包体积： Linux 容器需要打包一整套依赖甚至是简化的 OS 根目录结构。而一个编译好的功能完善的 Wasm 模块体积常常不到几兆甚至仅仅几十 Kb，极大地加快了存储及网络利用效率。
当 Docker 遇上 WebAssembly
在现代的容器生态系统中，Wasm 并不被看作是要被取代传统的 Docker 或者 Kubernetes 的技术，而是成为了一种 与 Linux 容器互补并且共生 的全新工作负载类型。
目前，这通过 OCI (Open Container Initiative) 和 CRI 标准实现了集成上的统一：
- 将 Wasm 打包为 OCI 镜像：虽然内容并非传统的 Linux RootFS，但是通过标准化的打包工具同样可以将应用程序及其
.wasm构建结果转化为一个可以被推送至 Docker Hub 或其他 registry 的标准化镜像规范。 - 通过容器运行时直接执行：Docker 已经与如 WasmEdge 和 Spin 等高性能的企业级 Wasm 运行时进行了官方集成合作。
如今在 Docker Desktop 或者集成了 containerd 的环境中，我们可以十分简易地以类似普通镜像的形式去拉取并运行一个基于 Wasm 编译的后端服务（通过指定相应的 --platform 或者是特别的 --runtime=io.containerd.wasmedge.v1 设置），将其如同对待一个标准应用进程一样让 Docker 为其接管日志、配置相关的网络端口映射，甚至通过 Docker Compose 将一个普通的数据库容器实例与一个 Wasm 微服务实例协同起来混布。
总结
随着技术底座如 WASI 规范不断的成熟完善（例如提供完备的套接字网络支持以及系统资源访问支持），我们有理由相信不仅是边缘计算与无服务器调用，会有越来越多对于速度和安全性有极高指标要求的云原生后端微服务开始采用这一颠覆传统边界的轻量级“微型智能体”架构。在可见的将来，Wasm 势必成为云原生与 Docker 生态的重要拼图。