8.3 WebAssembly：跳過作業系統核心的應用程式級「軟體虛擬機」#

虛擬化的第四層樓#

回顧本書的隔離層次演化，可以畫出一座四層樓：

第 1 層：硬體虛擬機（VM/MicroVM）
        隔離單位：整台機器，含作業系統
第 2 層：系統容器
        隔離單位：核心上的行程視圖
第 3 層：語言虛擬機（JVM、CLR）
        隔離單位：特定語言的執行環境
第 4 層：WebAssembly（Wasm）
        隔離單位：應用本身——連 OS 都不需要

WebAssembly 是隔離粒度的極小值：不是虛擬出一台機器，而是直接虛擬出一個「可執行程式碼的 CPU 介面」。

誕生史：瀏覽器的性能絕境#

2013 年前後，瀏覽器內跑重運算（遊戲引擎、影音處理、CAD）的困境已到極限：JavaScript 是動態型別、直譯＋JIT 混合執行，對 C/C++ 編譯目標極不友善。Mozilla 的 asm.js（2013，Alon Zakai 的 Emscripten 生態產物）先證明「JS 子集可以逼近原生速度」，隨後 2015 年，Mozilla、Google、微軟與蘋果史無前例地聯手宣布 WebAssembly 專案——四大瀏覽器競爭者共同制定一個二進制指令格式。2017 年，四大瀏覽器全部預設支援。

Wasm 的核心定位（W3C 2019 正式標準）：
  · 可移植的二進制指令格式（類似「通用組語」）
  · 沙盒執行環境：程式只能存取被明確「進口」的能力
  · 語言中立：C/C++/Rust/Go/… 皆可編譯為 Wasm
  · 近原生速度：線性記憶體＋靜態型別＋AOT/JIT 友善

沙盒的哲學：能力導向（Capability-based）#

Wasm 與前面所有層級的根本差異，在於預設零權限：

VM/容器模型：白給一個「世界」（檔案系統、網路、PID 空間），
             再靠邊界擋住越權
Wasm 模型：  什麼都不給。要碰檔案？要連網路？
             必須由宿主「明確 import」一個能力進來

這是 1970 年代能力導向安全（capability-based security）思想的實現——數十年的安全理論，終於找到了一個足夠輕的載體。攻擊面理論上也因此達到極小：沒有系統呼叫介面可打，除非宿主自己開了門。

從瀏覽器走向雲端邊緣：WASI 與邊緣運算#

瀏覽器之外的世界很快發現 Wasm 的價值。2019 年，Mozilla 提出 WASI（WebAssembly System Interface）：一組標準化的「系統介面」，讓 Wasm 在伺服器上以沙盒方式存取檔案、時鐘、隨機數等資源。生態隨之爆發：

邊緣運算的採用（代表性案例）：
  · Cloudflare Workers：以 Wasm 為底，全球數百個節點
    上執行客戶代碼，冷啟動毫秒級
  · Fastly Compute@Edge：同樣的 Wasm 邊緣策略
  · Fermyon、Wasmer、wasmCloud：Wasm 伺服器生態
  · 企業內部：外掛系統（Envoy/Istio 的 Wasm 外掛）、
    AI 推理的攜帶式模型載體、跨平台 CLI 工具

對比第 8.1 的冷啟動數字，Wasm 更是登峰造極：沒有核心、沒有 VM、沒有行程模型——啟動開銷接近函式呼叫的等級（微秒～毫秒），記憶體占用以 KB 計。

Wasm 能取代 Docker／VM 嗎？#

2019 年，Docker 共同創辦人 Solomon Hykes 留下名言：

「如果 2008 年就有 WASM＋WASI，我們根本不需要創造 Docker。看得出它有多重要。WASM 是基礎計算的範式轉移。」

但範式轉移的速度受制於生態現實，2020 年代的誠實結論是互補而非取代：

需求	最佳載體
完整 Linux 生態（glibc、萬千套件）	容器/VM
需要完整系統呼叫與驅動的應用	VM/容器
高密度、短生命、不可信代碼	Wasm 或 MicroVM
邊緣、跨平台、外掛化	Wasm
極端安全沙盒	Wasm ＋機密硬體

歷史關聯：Wasm 讓「虛擬機」一詞的兩個身世——硬體幻覺（CP-40 之後）與語言沙盒（UCSD Pascal 之後）——在本書第 2.3 節分岔的兩條線，於 2019 年前後重新匯流。而當 AI 時代到來、運算與資料都成為需要「邊算邊保密」的資產時，隔離的故事將進入最深的水域：連雲端的管理員也不該看見的世界。