WASI 0.3 WebAssembly Serverless 冷啟動 2ms 優化指南

我第一次看到 WASI 0.3 的 benchmark 數據時，說實話有點不敢相信。冷啟動 2ms？這比我按一下鍵盤的延遲還短。但跑完自己的測試之後，我確認這是真的——WebAssembly Serverless 的時代，真的來了。

如果你對 WebAssembly 後端開發還不太熟，建議先看那篇基礎介紹。這篇會聚焦在 WASI 0.3 的技術突破，以及它如何徹底改變 Serverless 的遊戲規則。

WASI 0.2 的痛：Pollable Handle 和 async 的缺席

要理解 WASI 0.3 為什麼這麼重要，得先聊聊 WASI 0.2 有多痛苦。

WASI 0.2 引入了 Component Model，這是好事。但它處理非同步操作的方式簡直是折磨——用的是 pollable handle。你沒看錯，就是手動 polling。想像一下，在 2025 年寫後端程式，你還得手動輪詢 I/O 狀態，這感覺像回到了 90 年代。

// WASI 0.2 的 async 處理方式（痛苦版）
let request = outgoing_handler::handle(req, None)?;
let response_pollable = request.subscribe();

// 手動 poll... 真的嗎？
loop {
    let ready = poll::poll(&[&response_pollable]);
    if ready.contains(&0) {
        let response = request.get().unwrap().unwrap();
        break;
    }
}

這段程式碼看起來就讓人不舒服。更糟糕的是，這種模式讓編譯器和 runtime 很難做最佳化，因為控制流被手動 polling 打斷了。結果就是，WASI 0.2 的非同步效能遠不如原生的 async/await 實作。

WASI 0.3 帶來了什麼：原生 async/await

WASI 0.3 最大的改變就是引入了 stream<T> 和 future<T> 這兩個一等公民的 async 原語。不再需要 pollable handle，不再需要手動輪詢。

// WASI 0.3 的 async 處理方式（優雅版）
async fn handle_request(req: IncomingRequest) -> OutgoingResponse {
    let body = req.body().await;  // 就是這麼簡單
    let db_result = database::query("SELECT...").await;
    let api_result = http::fetch("https://api.example.com").await;
    
    OutgoingResponse::new(200, format!("{db_result} + {api_result}"))
}

看到了嗎？跟你寫 Rust 的 tokio async 或 JavaScript 的 async/await 幾乎一樣直覺。這不只是語法糖——底層的執行模型完全不同。stream<T> 提供了背壓（backpressure）控制，future<T> 則是真正的協作式排程。

對 runtime 來說，這意味著可以做更激進的最佳化：任務切換不需要系統呼叫、記憶體分配可以預測、I/O 操作可以批次處理。

冷啟動效能實測：2ms vs 300ms

說了半天技術細節，來看真正的數據。我用以下環境做了對比測試：

方案	冷啟動	記憶體	Binary Size
Node.js Lambda	~310ms	~128MB	~45MB
Python Lambda	~450ms	~180MB	~60MB
Go Lambda	~85ms	~32MB	~12MB
WASI 0.2 (Spin)	~8ms	~4MB	~2MB
WASI 0.3 (Spin 3)	~2ms	~2MB	~800KB

2ms 的冷啟動意味著什麼？意味著你根本不需要 warm pool。傳統 Serverless 為了避免冷啟動懲罰，得維護一個預熱的 instance pool，這本身就是一筆額外成本。WASI 0.3 讓冷啟動變得幾乎無感知，每個請求都可以是「冷」的，但使用者完全察覺不到。

記憶體方面的改進也很誇張——2MB 的 footprint 讓你在同一台機器上跑的 instance 數量暴增 64 倍。這對成本控制是巨大的利好。

Fermyon Spin + Wasmtime 37 實戰

目前支援 WASI 0.3 最成熟的平台是 Fermyon Spin 3.0，底層用的是 Wasmtime 37 runtime。讓我帶你走一遍從零開始的流程。

# 安裝 Spin 3.0
curl -fsSL https://developer.fermyon.com/downloads/install.sh | bash
spin --version  # 確認 3.0+

# 建立新專案
spin new -t http-rust my-api
cd my-api

Spin 的開發體驗非常流暢。它用 TOML 做設定，支援熱重載，而且內建了 KV store、SQLite、outbound HTTP 等常用功能。寫一個 API endpoint 大概長這樣：

use spin_sdk::http::{IntoResponse, Request, Response};
use spin_sdk::http_component;

#[http_component]
async fn handle_request(req: Request) -> anyhow::Result<impl IntoResponse> {
    let body = req.body();
    let kv = spin_sdk::key_value::Store::open_default().await?;
    
    kv.set("last_request", body).await?;
    
    Ok(Response::builder()
        .status(200)
        .header("content-type", "application/json")
        .body("{\"status\": \"ok\"}")
        .build())
}

注意那個 async fn——這在 WASI 0.2 是不可能的。現在你可以在 handler 裡面自然地做 await，不需要任何 workaround。

Component Model 與多語言互操作

WASI 0.3 的另一個殺手鐧是搭配 Component Model 的多語言互操作。你可以用 Rust 寫效能關鍵的模組、用 Python 寫業務邏輯、用 JavaScript 寫膠水程式碼，全部編譯成 WASM Component，然後在同一個 runtime 裡無縫互動。

這對於像我們這種用多語言技術棧的團隊來說是天大的好消息。之前跨語言呼叫不是走 HTTP 就是走 gRPC，現在直接在記憶體內呼叫，零序列化開銷。跟 TypeScript 的型別安全理念一樣，Component Model 用 WIT（WebAssembly Interface Types）定義介面，保證跨語言的型別安全。

從 Docker 到 WASM：遷移路線圖

好，假設你被說服了，想從 Docker 遷移到 WASM。我的建議是分階段進行，不要一步到位。

Phase 1：新服務直接用 WASM

最低風險的起點。新開發的微服務直接用 Spin/WASI 0.3，不影響現有架構。選一個流量不大但有代表性的服務開始。

Phase 2：無狀態服務遷移

把現有的無狀態 API 服務逐步遷移到 WASM。這類服務遷移成本最低，效益最明顯。通常是 API Gateway 後面的一些輕量級處理函式。

Phase 3：有狀態服務評估

有狀態的服務（比如 WebSocket 連線管理）需要更謹慎。WASI 0.3 的 stream<T> 理論上支援，但生態圈的成熟度還需要時間驗證。

遷移過程中，像 Rust 後端開發的經驗會很有幫助，因為 WASM 的主力語言目前還是 Rust。

生產環境注意事項

雖然我對 WASI 0.3 很看好，但也必須誠實說幾個目前的限制：

除錯工具還不成熟：相比 Docker 生態圈豐富的除錯工具，WASM 的 debug 體驗還是比較原始。DWARF debug info 支援正在改善，但還沒到 production-ready
網路限制：WASI 目前不支援 listen socket，只能做 outbound 連線。要當 server 得靠 runtime（Spin）來處理 inbound
生態圈大小：npm 有 200 萬個 package，crates.io 有 15 萬個 crate，但能編譯成 WASM 的庫還是少數
Observability：OpenTelemetry 的 WASM 支援剛起步，分散式追蹤需要額外配置

這些都不是根本性的阻礙，但在規劃遷移時要考慮進去。我建議先在非關鍵路徑上試水溫，累積經驗後再擴大範圍。