比 Docker 启动快 100 倍？WebAssembly（Wasm）怎么成了下一代服务端运行时

如果有人告诉你，有一种技术能让你的服务在 不到一毫秒 的时间里启动就绪，占用的内存只有 几兆字节，打包出来的文件小到能塞进一条微信消息里，你大概率会觉得这是在做梦。毕竟我们今天习以为常的 Docker 容器，冷启动动辄几百毫秒甚至好几秒，一个干净的镜像也得几十上百兆。可这个"做梦"的技术不仅真实存在，而且正跑在 Cloudflare、Fastly 这些巨头的数据中心里，每天处理着上千亿次请求。

更反直觉的是，这项技术的老家根本不在服务器，而在你的浏览器。它叫 WebAssembly，简称 Wasm。它一开始是被设计来让 C++、Rust 这类"重武器"语言在网页里跑出接近原生的速度，好替代又慢又笨重的 JavaScript。那么问题来了：一个浏览器里的加速技术，是怎么一路杀到服务端，甚至被 Docker 的创始人公开说"要是 2008 年就有它，我可能就不会发明 Docker 了"？

Wasm 是什么：先说它在浏览器里凭什么快

要理解 Wasm 为什么能上服务器，得先弄明白它在浏览器里是怎么工作的。早期的网页想做点复杂的事——比如视频剪辑、3D 游戏、科学计算——全靠 JavaScript。可 JS 是个解释执行的脚本语言，再怎么优化，离 C++、Rust 编译出来的机器码还是有差距。浏览器厂商们想了个办法：能不能让这些高性能语言直接编译成一种浏览器能高效执行的中间格式？于是 Wasm 诞生了。

你可以把 Wasm 想象成一种"万能字节码"。不管你用 Rust、C++ 还是 Go 写的代码，都先编译成 Wasm 这套中间指令，然后丢进浏览器里一个专门的虚拟机去跑。它跑在浏览器给的一块"线性内存"里，被严格框死边界，既快又安全。实测下来，Wasm 的运行速度能达到原生代码的 70% 到 95%，比 JavaScript 快好几倍。这才是它在浏览器里站稳脚跟的根本原因。

WASI：给 Wasm 一把打开现实世界的钥匙

但浏览器里的 Wasm 有个致命限制：它根本碰不到真实的文件系统、网络、时钟这类系统资源，因为浏览器不让你碰。这也就意味着它只能待在前端。想让它上服务器，必须解决一个问题——怎么让 Wasm 安全地访问操作系统？

答案就是 WASI（WebAssembly System Interface，WebAssembly 系统接口）。打个比方，WASI 就像是 Wasm 世界的"POSIX 标准"。POSIX 是 Unix 系操作系统约定好的一套接口，比如"打开文件用 open、读写用 read/write"。WASI 干的是同样的事，只不过它是给 Wasm 模块用的。有了 WASI，一段 Wasm 代码就能申请读写某个文件、发起一个网络请求，而不必关心底下是 Linux、Windows 还是 Mac。

更关键的是，WASI 引入了一种叫"基于能力（capability-based）"的安全模型，而且是默认拒绝。什么意思？一个 Wasm 模块在启动的时候，默认什么系统权限都没有——不能读文件、不能联网、啥也干不了。你得像一个发权限的人，明确地"授予"它某个能力，它才能用。这种"没授权就啥也不是"的设计，让 Wasm 从骨子里就是安全的，而不是事后打补丁。Docker 的创始人 Solomon Hykes 那句名言正是针对这点："如果 2008 年就有 WASM+WASI，我们根本不需要发明 Docker。"

到了 2024 到 2025 年，WASI 的 Preview 2 版本稳定了下来，新增了对 HTTP 服务、键值存储、完整套接字（socket）的支持，还带来了组件模型（Component Model）和 WIT 接口定义语言。组件模型解决了一个老大难问题：不同语言编译出来的 Wasm 模块，怎么像积木一样拼在一起、互相调用？现在它们通过标准化的接口互相通信，连序列化开销都省了。至此，Wasm 上服务器的路彻底打通。

和 Docker 正面对决：毫秒启动、几兆内存

现在到了最刺激的部分——拿 Wasm 跟 Docker 容器直接比。我们从三个硬指标看：

第一，冷启动速度。冷启动指的是"从完全没运行，到第一次能接请求"花的时间。Docker 容器要干的事太多了：得启动一个被虚拟化的操作系统用户空间、加载语言运行时（比如 Node.js、Python）、初始化网络命名空间，一套下来几百毫秒到好几秒。而 Wasm 模块呢？它不需要启动操作系统，只是把一个提前编译好的二进制文件加载进一块沙盒内存，然后直接开始执行。实测数据很夸张：一个 Alpine 容器冷启动中位数大约 340 毫秒，最差情况接近 900 毫秒；而 Wasm 模块通常只要 0.3 到 5 毫秒。Cloudflare Workers 能做到 0.3 毫秒，Fermyon 的 Spin 能做到 0.5 毫秒。算下来，比容器快了大约 100 到 1000 倍。

第二，内存占用。一个最简单的 Node.js 容器，空闲时也要吃掉 30 到 80 兆内存；Python 容器更是 50 到 120 兆起步。而一个 Wasm 的 HTTP 处理函数，自身只占 1 到 5 兆，连运行时一起也就几兆。有个真实对比：在 64G 内存的机器上，同样一个 REST API 服务，容器大概能跑 1400 个实例，而 Wasm 能跑 约 18000 个——密度提升了十几倍。

第三，体积。容器镜像动辄 100 兆到 1 个 G；而 Wasm 模块普遍只有 0.5 到 5 兆。有开发者把一个 Node.js 写的微服务换成 Rust 编译的 Wasm，产物从 188 兆缩到了 0.5 兆，小了 99.7%，小到能直接当附件发微信。

天生安全的沙盒：默认啥也干不了

容器的隔离靠的是 Linux 的命名空间（namespace）和控制组（cgroup），相当于在同一台机器上划出不同的"房间"。但这套机制本质上还是共享同一个内核，历史上出现过容器逃逸（黑客从容器里钻出来控制了宿主机）的漏洞。而 Wasm 的隔离是在运行时层面就焊死的：模块运行在一块线性内存里，默认根本没法发起系统调用，所有外部访问都得通过 WASI 明明白白地授权。换句话说，即便你的 Wasm 代码被人塞进了恶意逻辑，它在没被授权的情况下也碰不到你的文件系统、网络和其他进程的内存。

边缘计算：Wasm 真正的主战场

光比参数还不够直观，Wasm 真正发光的地方是边缘计算。什么叫边缘？简单说就是把代码部署到离用户最近的节点上——可能就在你所在城市的机房里，而不是几千公里外的中心数据中心。Cloudflare Workers 把代码铺到了全球 300 多个地点，背后既有 V8 引擎也有 Wasm；Fastly 的 Compute 平台每天处理上千亿次 Wasm 请求，官方说单核 CPU 上能跑 超过 10 万个 Wasm 隔离实例——你拿 Docker 试试？服务器当场就冒烟了。

Wasm 给 Serverless（无服务器计算）带来的改变是颠覆性的。传统 Serverless 最怕"冷启动"：为了省钱，空闲时把实例缩到零，等请求来了再启动，结果用户要等上几百毫秒甚至几秒。Wasm 因为启动只要不到一毫秒，"缩到零"这件事几乎没有代价，于是真正的按用量计费、随叫随到成了现实。Fermyon 的 Spin 也是同理，主打"亚毫秒冷启动的 serverless"。字节跳动用 Wasm 做广告算法的热更新，发布耗时从分钟级降到秒级。连 AI 推理都被它改造了：传统容器部署一个大模型推理服务，镜像加模型动辄 15 个 G，冷启动要好几分钟；换成 Wasm 封装，文件只有几十兆，冷启动压到几毫秒，刚好够"即时"响应。

那 Docker 是不是要被淘汰了？

别急着给 Docker 写悼词。Wasm 不是来"杀死"容器的，它只是更适合一类特定工作。容器依然是无可替代的：跑数据库、消息队列这种长时间运行、有状态、依赖一大堆系统库的服务，容器是天作之合；需要 GPU、特定内核特性、复杂操作系统依赖的应用，也得靠容器。Wasm 的主场是短命、无状态、对延迟极其敏感的那类：Serverless 函数、轻量微服务、边缘计算、插件系统、以及那些需要让用户在你平台里跑自定义代码的场景。Envoy 这类代理已经支持用 2 兆的 Wasm 模块替代几十兆的 sidecar 容器来做鉴权和限流了。

一句话总结：Docker 负责"重"，Wasm 负责"快"和"密"。未来更可能是"容器当底座，Wasm 跑在容器里做精细活"，而不是谁取代谁。

写在最后：给你的几条实在建议

• Wasm 最初是为浏览器提速而生的，靠"万能字节码 + 沙盒"跑出接近原生的速度。
• WASI 是 Wasm 上服务器的钥匙，用"默认拒绝"的能力模型把安全焊进底层。
• 对比 Docker：冷启动快 100 到 1000 倍（毫秒级）、内存省十几倍、体积缩到 1% 以内。
• 边缘计算是 Wasm 的主场，让"缩到零"的 serverless 真正低成本落地。
• 容器不会被淘汰，它和 Wasm 是互补关系，按"重 vs 快"分工协作。

延伸阅读

更多相关攻略推荐：Ollama AI系列(2)：VPS上的AI推理与API应用、Ollama AI系列(2)：VPS上的AI推理与API应用、【CPU选型 01】搭载 AMD Ryzen 9950X 的 VPS、ARM / Ampere 席卷 VPS：性价比真香还是兼容陷阱？、Ollama AI系列(2)：VPS上的AI推理与API应用。