shubham shaw

近十年來，我部署企業軟體的心智模型一直圍繞在容器上，容器是一種輕量級套件，能將應用程式與其執行所需的所有作業系統檔案一起打包。最近，我決定走出舒適圈，暫時放下 C# 與傳統雲端環境，探索一項採取截然不同做法的技術：伺服器上的 WebAssembly。

多數工程師都知道 WebAssembly，通常簡稱 Wasm，它是一種二進位指令格式，是一組精簡的機器可讀程式碼，目的是讓 Rust 或 C++ 等語言能在網頁瀏覽器中以接近原生的速度執行。吸引我注意的是，Wasm 正走出網頁，進入伺服器基礎設施，特別是在邊緣運算領域，也就是在靠近使用者的實體伺服器上處理資料，以降低網路延遲。

這種轉變仰賴一項較新的標準，稱為 WASI，亦即 WebAssembly System Interface（WebAssembly 系統介面）。它是一組標準化規則，讓 Wasm 程式能在任何瀏覽器之外，安全地與主機伺服器的檔案系統、時鐘和記憶體互動。你可以把 WASI 想像成一個安全的翻譯器，讓沙盒化的程式向作業系統請求特定資源，而不會讓該程式存取機器上的其他部分。

我過去多年管理企業微服務（microservices），也就是透過網路彼此通訊的小型獨立軟體服務。兩者的設計哲學差異相當明顯。傳統容器會攜帶大量額外負擔，因為它們包含了底層作業系統的部分，通常需要數百 MB 的磁碟空間，而且啟動時有明顯的延遲。另一方面，WebAssembly 二進位檔只包含編譯後的應用程式邏輯，通常只有幾 MB 大小，而且能在不到一毫秒的時間內開始執行。

你可以把傳統容器想像成裝滿貨物的搬家卡車，需要時間停妥、卸貨、布置完畢才能開始工作。而 WebAssembly 二進位檔則更像輕便的快速搭設帳篷，一旦拆包就能立刻展開。

在我最近使用 Rust 與伺服器端 Wasm 執行環境撰寫簡單後端服務的實驗中，冷啟動（cold start）效能非常驚人。冷啟動指的是伺服器啟動全新應用程式實例以處理傳入流量時所產生的初始延遲。能夠在普通硬體上以幾乎零延遲與極低記憶體消耗啟動數百個隔離任務，為事件驅動工作流程開啟了令人興奮的可能性。

同時，探索新興技術也意味著要面對現實的取捨。這個生態系仍處於早期階段。對正在執行的 Wasm 二進位檔進行除錯，目前尚未能提供成熟企業開發環境所具備的流暢、逐步追蹤體驗。此外，許多既有的資料庫驅動程式與遙測函式庫（telemetry libraries），也就是用來記錄系統活動與追蹤錯誤的工具，仍處於適配 Wasm 環境的階段。

我並不期待 WebAssembly 在短期內取代傳統容器，適用於所有企業工作負載。相反地，它更像工具箱中一把強大的新工具，特別適合高密度、低延遲，且即時啟動時間至關重要的任務。花時間了解這個生態系如何運作，也提醒了我伺服器架構領域仍有許多創新的空間。

對於正在追蹤後端基礎設施變遷的工程師們，你們目前是否在瀏覽器之外測試 WebAssembly？哪些缺少的功能或工具落差，正在阻礙你們在專案中採用它？

webassembly #rust #backend #devto