【系统架构设计】WebAssembly 架构：浏览器之外的运行时革命
内容提要
本文探讨WebAssembly（Wasm）在服务端作为隔离单元的应用，对比V8 Isolate，分析其沙箱机制、WASI 0.2接口、能力安全模型及组件模型。文章指出Wasm适合多语言插件与边缘计算，但长生命周期、线程支持及完整POSIX需求仍依赖容器，并建议选型时优先pin WASI 0.2，为0.3演进预留空间。
延伸解读
Wasm 与容器的边界：不是替代，而是分工
文章明确指出，Wasm 并非要取代容器，而是将“轻量”的边界往前推了一步。对于需要完整 POSIX、长生命周期或有状态负载，容器仍是必要选择。架构师应基于负载特性选择隔离单元，而非盲目追求 Wasm 化。
WASI 0.2 与 0.3 的选型策略
WASI 0.2 是当前稳定版本，适合生产环境；0.3 虽已发布，但线程等特性仍在 roadmap 上。建议新组件 pin 0.2，并通过抽象自定义 WIT 为未来迁移预留空间，避免依赖未稳定的预览特性。
能力安全模型的实际落地
Wasm 的能力安全模型通过 import 表和 preopen 实现最小权限，但 embedder 的配置至关重要。错误地暴露敏感路径或过度授权会破坏沙箱安全性。生产环境应显式管理权限矩阵，并记录审计日志。
Q&A
WebAssembly 在服务端作为隔离单元相比 V8 Isolate 有什么优势？
WebAssembly 的优势在于语言无关、可移植性好，支持多语言插件，且沙箱机制基于类型化验证和显式 import/export 边界，不依赖特定宿主 VM。相比之下，V8 Isolate 与 JavaScript 生态深度绑定，无法运行任意已编译二进制，且需长期承担 Spectre 类边信道的缓解成本。
WASI 0.2 和 0.3 的主要区别是什么？
WASI 0.2 是当前稳定版本，基于 WIT 接口和组件模型，提供 wasi:cli/command 和 wasi:http/proxy 等标准 world。WASI 0.3.0 于 2026-06-11 发布，核心变化是将异步原语（async func、stream、future）下沉到 Component Model Canonical ABI，并移除 wasi:io 包。0.3.x 仍在规划抢占式线程和零拷贝 stream 优化。
WebAssembly 的沙箱机制是如何实现内存隔离的？
WebAssembly 使用线性内存模型，所有内存访问都经过边界检查，越界会触发 Trap。guest 无法直接访问 host 内存，只能通过 import 函数与外部交互。Wasmtime 还默认在 linear memory 前放置 2GB guard region，并可选启用 Spectre 缓解。
什么是 WASI 的 preopen 机制？它如何实现能力安全？
Preopen 是 embedder 在实例化前将 host 目录映射为 guest 内虚拟路径的机制，并生成只针对该子树的 descriptor。guest 只能访问被授予的目录，无法通过 ../ 逃逸，因为上层 descriptor 根本未授予。这体现了能力安全模型：持有 handle 才能操作，无全局权限。
在服务端场景中，WebAssembly 适合哪些应用？不适合哪些？
Wasm 适合边缘 HTTP 插件、SaaS 插件沙箱、多语言组件组合等场景，因其启动快、内存安全、支持多语言。不适合需要完整 POSIX（如 fork/exec）、GPU 计算、GB 级内存状态或强隔离合规要求的负载，这些应使用容器或 microVM。
Wasmtime 提供了哪些资源限制机制来防止恶意插件消耗过多资源？
Wasmtime 提供多种配置：静态/动态内存模式、fuel（指令数限制）、epoch interruption（协作式抢占）、max memory pages（内存上限）等，用于 CPU 配额、超时控制和防止 OOM。
WebAssembly 组件模型相比传统 Core Module 有哪些架构优势？
组件模型提供模块化（接口与实现分离）、虚拟化（同一接口多实现，可 polyfill）和多语言组合（不同语言编译的组件可链接）。它基于 WIT 类型，不依赖语言运行时布局，增强了跨语言互操作性。
在边缘计算场景中，选择 V8 Isolate 还是 WebAssembly 组件？
如果团队已在 Cloudflare Workers 生态，且主要用 JavaScript，Isolate 更成熟；如果需要多语言支持、标准 WASI 可移植组件或私有化部署，Wasm 组件更合适。两者也可共存，Workers 支持 Wasm guest。
