Cloudflare 與 Fastly 押注 WASM 元件取代無伺服器容器

WebAssembly 元件模型已跨越生產門檻。Cloudflare Workers 與 Fastly 運算資源均在 2025 年第一季將 WASI 0.2 元件切換為預設部署工件，實質上宣告容器式無伺服器模式並不適合邊緣原生工作負載。此一轉變將 WebAssembly 重新定位為無伺服器運算資源的基礎單位，而非瀏覽器外掛程式的利基執行環境。

Cloudflare 在轉換之際宣布原生 WIT IDL 繫結，使 Rust、Go、Python 與 C++ 模組之間可直接互通，無需容器網路所要求的共享記憶體操作。此區別屬架構層級，而非表面修飾。容器將檔案系統與網路名稱空間暴露為基本元素——此模式源自分散式伺服器，從未與邊緣環境所要求的無狀態、請求範圍執行完全調和。WASM 元件則改為暴露型別化介面，使模組間的契約在執行時期水準上明確、可驗證且可強制執行。

Fastly 更進一步。該公司圍繞 Bytecode Alliance 的元件模型重建其整個運算管線，此專案由 Mozilla 的 Luke Wagner 與 Fastly 的 Till Schneidereit 在 W3C WebAssembly 工作小組內主導推動。在 Fastly 於 3 月發布的企業基準測試中，重建後的管線相較容器化對等方案，冷啟動延遲改善三至五倍。對請求範圍的邊緣函式而言，冷啟動效能並非邊際考量——它決定平台能否以 CDN 首創的細緻度有效服務流量。

無論以何種標準衡量，這些數字都意義重大。根據 Bytecode Alliance 隨 Fastly 公告一同揭露的數據，執行 WASM 元件模型的平台合計每日服務超過 500 億次請求。此數字涵蓋 Cloudflare 與 Fastly 的部署，以及其後跟進採用該標準的鄰近平台。每日 500 億次請求約占全球網際網路流量的 10% 至 15%，實際比例取決於你信賴哪一方的分母計算方法。

容器模型在可靠性或安全性上並未落敗，它輸在開銷。一個搭載製程.js 執行環境的最小 OCI 容器映像檔，未壓縮時體積達 50 至 120 MB。即使採用延遲載入與分層檔案系統快取，容器執行環境仍須在應用程式程式碼執行任何一行之前，啟動程序、初始化環境並啟動 JavaScript 引擎。對於在數千個獨立租戶之間處理請求的 CDN 邊緣節點而言，這項初始化成本會在每個冷路徑上累積成可量測的延遲。WASM 元件從設計上就避開了這個問題。針對 WASI 0.2 編譯的元件通常僅 100 至 400 KB。執行環境額外占用數百 KB，並由節點上所有租戶共享。初始化時間從數百毫秒降至個位數毫秒。

WIT 介面描述語言正是此模型贏得「架構性」標籤的關鍵。元件在 WIT 中宣告其匯入與匯出——需要哪些能力、接受哪些資料型別、產出什麼內容。執行環境在邊界強制執行這些限制，而非依賴慣例或近似慣例的工具（如環境變數與磁碟掛載）。若元件宣告需要網路存取，執行環境便僅授予該權限，不多不少。若元件宣告接受 UTF-8 字串並回傳 32 位元無號整數，執行環境便拒絕任何傳入原始位元組緩衝區的嘗試。這不是安全作秀，而是靜態型別在大型程式碼庫中價值的相同原則，應用於獨立部署工件之間的邊界。

這對平台工程的影響是具體的。建置邊緣函式的團隊不再需要考量容器映像登入、Dockerfile 維護，或本地 Docker 版本與生產環境版本分歧時浮現的細微不相容問題。元件工件在確定性上，是容器映像（儘管有分層抽象）歷來所未能達到的。在本地建置、發布至邊緣，並預期位元級完全一致的行為。當除錯一個僅在特定 PoP 的特定請求模式下浮現的延遲回歸時，這種可重現性絕非小事。

更廣泛的生態系正在關注。AWS 尚未就其自身邊緣執行環境意圖發布正式聲明，但 Lambda 團隊已出席前兩屆 WasmCon 工作坊，且西雅圖地區的職缺貼文與 WASI 相關能力高度吻合。Google 雲端與 Cloudflare Workers 的合作關係顯示，這家超大規模雲端業者承認此轉變正在發生，即使其尚未將自身運算資源投入元件模型。開放性問題在於，AWS 是否會在 Lambda 中原生採用元件模型，抑或繼續將其作為既有執行環境之外的選用執行環境提供。

W3C WebAssembly 工作小組於 2024 年底定稿 Component Model 規範，消除了企業採購團隊對於押注不穩定標準所能提出的最後一個合理異議。WASI 0.2 隨附正式規範、以 wasm-tools 形式提供的參考工具，以及日益擴充的語言 SDK 集合，這些 SDK 編譯至元件目標而非獨立模組。該工具鏈尚不如 Docker 的 CLI 那般易用，但已跨越小型團隊無需大量客製整合工作即可採用的門檻。

對於當今評估邊緣平台的開發者而言，選擇已大幅收窄。不將 WASM 元件視為一級部署目標的平台，等同於暗示你接受冷啟動延遲、映像管理負擔，以及完整程序隔離所帶來的安全曝險面等容器稅。對某些工作負載而言，這些是合理的取捨。但對於構成 CDN 邊緣邏輯多數的請求範疇、無狀態函式而言，這些是糟糕的取捨。算過帳的企業已用其部署管線投票。現在的問題不在於元件模型是否勝出，而在於其餘觀望者以多快的速度採用。