WASM 將引領下一代計算範式 [譯]

WebAssembly 是一種新興的網頁虛擬機標準，它的設計目標包括：高可移植性、高安全性、高效率（包括載入效率和運行效率）、儘可能小的程序體積。2018 年 WebAssembly 第一個規範草案誕生，2019 年成爲 W3C 第四個標準語言。到了 2022 年底，WebAssembly 現在怎麼樣了...

• 作者：Anders Ranum, Justin Liu, David Carter

• 譯者：柴樹杉，凹語言作者，2 本 WASM 圖書作者，WASM 佈道者，目前在螞蟻從事 KusionStack 和 KCL 開源項目開發和推廣工作。

• 時間：Thought Leadership / October 18, 2022

零、背景

WebAssembly（簡稱 Wasm）是一個自誕生之日起就充滿潛力的技術，從 "JavaScript 殺手" 到 "雲計算的下一個前沿方向" 幾乎覆蓋了全部新興領域。同時在從雲計算項邊緣計算滲透，Wasm 已經遠遠超出了起作爲第四種 Web 標準語言的角色。甚至重新定義了應用軟件的開發模式，正逐漸接近其 “一次編寫，隨處運行” 的願景。

在 Wasm 從誕生到現在的幾年間，我們見證了從最開始的 Wasm 應用演示到爲數十億的頭部技術產品提供基礎設施支持。在同整個 Wasm 社區交談過程中，我們也發現雖然很多人很看好 Wasm 未來發展前景，但是也存在爭議和討論。

不過在 Sapphire，依然對圍繞 Wasm 的快速發展和 Wasm 開始爲更廣泛的計算世界帶來的新的可能性感到非常興奮。在本文中我們將探討什麼是 Wasm，爲什麼它很重要、今天它是如何被使用的、以及對這個生態系統的繁榮有什麼期待。我們不會詳細展開討論 Wasm 的歷史，但如果你對這些感到好奇可以看看 Lin Clark 的精彩系列文章。

一、什麼是 Wasm？

WebAssembly 正在沿着其名字中 Web 和 Assembly 兩個領域之外的方向發展，因此這是一個極其有誤導性的名字。

1. 首先它不完全是彙編語言。Wasm 是一種類似彙編字節碼的指令格式標準，它更像 LLVM-IR 那種比彙編語言更高一些抽象的中間語言（比如其中函數的參數和返回值定義更像高級語言）。開發人員也不需要完全手寫 Wasm；相反人們一般選擇使用其他高級語言（如 C、C++、Rust、Go、凹語言等）將他們的代碼編譯爲 Wasm。

2. 另外它不再只是 Web 網絡。雖然 Wasm 最初被設計爲 Web 瀏覽器的編譯目標，但它的影響並沒有停止。今天，使用與 Wasm 兼容的運行時，Wasm 文件可以在客戶端和服務器端執行，將使用範圍擴大到瀏覽器之外——稍後將進一步探討這些例子。

二、爲什麼 Wasm 很重要？

Wasm 有幾個關鍵的設計目標使其出生開始就自帶令人亮眼的關注：

2.1 首先 Wasm 是可移植的

雖然 Wasm 最初是爲 Web 設計的，而且今天所有主要的瀏覽器都提供對 Wasm 的支持。同時它也被設計爲針對低級虛擬機架構，其指令由物理機單獨翻譯成機器代碼。這意味着 Wasm 二進制文件最終可以在各種操作系統和芯片架構上運行——無論是在運行 X86 筆記本電腦的瀏覽器中，還是在內部或雲端的服務器上，在移動設備、物聯網設備上等等。

2.2 其次 Wasm 是多語言之下的一個標準

因爲 Wasm 是一個編譯目標，用於編程模塊的具體語言並不重要，重要的是是否有支持將該語言編譯到 Wasm。開發人員可以靈活地使用多種語言（如 C、C++、Rust、凹語言等）來構建二進制文件，並享受 Wasm 帶來的複利。這意味着不需要考慮諸多組件和庫鏈接等狗屁問題，只要他們都被編譯到 Wasm 可以用於支持一個單一的應用。

2.3 最後 Wasm 是輕量和高效的

作爲一個低級別的二進制指令格式，只需要較少的操作來將 Wasm 翻譯成優化的機器代碼。例如比如和 Javascript 進行比較（感興趣的話可以參考 Lin Clark 的一些分析文章）。Javascript 作爲解釋型語言，必須在運行時用即時編譯（JIT）進行編譯，並且必須經過獲取 / 解析 / 編譯 / 優化，最後才能執行和垃圾回收等步驟。

雖然 JavaScript 也可以被解析並轉換爲字節碼，但 Wasm 已經是原生的字節碼。另外 Wasm 也是靜態類型的，這使得大多數優化在其初始編譯時就已完成。最後 JavaScript 是動態類型的，需要在運行時進行優化和再優化，這共同導致了較難預測的性能。

這些優勢也體現在瀏覽器之外，特別是 Wasm 模塊的大小對於冷啓動有極大的優勢。目前，Serverless 的一個有問題是冷啓動緩慢。雖然 Serverless 爲開發者節省了管理後臺基礎設施和資源分配的時間，但如果該功能在冷態下被調用，就必須啓動新的資源從而帶來執行時間增加的額外成本。因爲 Wasm 模塊是非常輕量級的，和庫調用類似方式使得啓動時間可以大大減少（低至毫秒）。

2.4 Wasm 是默認安全的

Wasm 目標之一是安全，它在一個沙盒環境中執行，對主機運行時沒有初始可見性。這意味着對系統資源（如文件系統，硬件等）的訪問是受限制的，除非明確導入了對應的函數以支持。因此 Wasm 極大限制了攻擊面，實現了多租戶環境中不受信任的代碼安全受限地執行。這種安全模式是一個關鍵的促成因素，允許開發人員使用插件和用戶提交的代碼來擴展現有的應用程序，我們將在下面進一步探討這一使用情況。 

三、Wasm 現在是如何使用的？

3.1 客戶端使用案例

3.1.1 瀏覽器中的多語言支持

開發客戶端的流行語言不多，大部分都是 Javascript 構建的。應用程序的語言在歷史上是有限的，今天大多數現代網絡應用程序是用 Javascript 構建的。而瀏覽器和前端框架對 Wasm 的支持已經開始打開閘門，使開發者更容易在瀏覽器中編譯和執行其他流行語言。現在開發者可以選擇在瀏覽器中直接運行 C、C++、Rust、和 Go 等語言。此外，像 Zig 這樣的新興系統語言已經爲 Wasm 增加了很好的支持。而其他專門從 Wasm 設計的語言也已經出現，包括 AssemblyScript、Grain、Motoko 和凹語言等。

3.1.2 高性能的網絡應用

已經有一些公司使用 Wasm 來顯著提高他們的網絡應用程序的性能。例如，Figma（剛剛被 Adobe 以 200 億美元收購），一個基於瀏覽器的協作界面設計工具，使用 C++ 構建其渲染引擎，最初將其代碼交叉編譯到稱爲 asm.js 的 Javascript 子集。在之前因爲面臨 Javascript 固有的優化限制，在改用 Wasm 後 Figma 的加載時間快了 3 倍，無論正在加載的文檔大小如何。

其他價值數十億美元的公司也已經在產品採用了 Wasm。比如 Adobe 的 Photoshop、Autodesk 的 AutoCAD。重新利用現有的代碼庫，用 Wasm 將整個桌面應用移植到網絡上已經是真實發生的事情。其他有趣的例子包括移植成熟的視頻遊戲和項目，如完全在瀏覽器中運行的 Doom3 和 Angrybots，Unity 明確地將其 WebGL 構建的編譯目標轉換爲 Wasm。

除了移植已有的應用，我們還看到一些公司利用 Wasm 建立新的功能，這些功能在以前會受到性能限制的制約。 一些例子包括 Runway，這是一個下一代內容創作套件，使用 Wasm 來支持其視頻編解碼器和媒體操作，以及 StackBlitz，使用 Wasm 來支持純 Web 的 IDE 開發環境，這比以前僞在線 IDE 外掛一個遠程服務器拖油瓶的方式有着更好的安全性和性能優勢。

3.1.3 瀏覽器內的數據庫和分析

我們已經開始看到數據庫的出現，它們利用 Wasm 的執行性能，使以前的服務器端分析工作負載更接近數據的存在。這裏的例子包括 DuckDB-Wasm，它使用 Wasm 爲瀏覽器的中分析 SQL 數據庫提供動力。以及 SQL.js，它允許開發人員完全在瀏覽器中創建和查詢 SQLite 數據庫。

3.2 WASI：突破瀏覽器的桎梏

鑑於 Wasm 模塊在默認情況下不能訪問被明確授權的功能，純 WASM 其實只能實現一些純運算的功能。在上面的例子中，瀏覽器本身代表 Wasm 模塊對系統資源的訪問控制界面（例如，文件系統、I/O、時鐘、全局變量等）。然而當我們在瀏覽器之外使用 Wasm 時需要什麼呢？ 

在實踐中，運行時實如何提供對系統資源的訪問方面有很大的不同。這就是 WebAssembly 系統接口（WASI）出現的地方。WASI 是 W3C 的一個項目，是一個供應商中立的、模塊化的標準化 API 集合，正如其名稱所示，它作爲 Wasm 模塊和操作系統之間的接口，促進與主機運行時的通信，並以一致的方式使用選定的系統資源。

當然，WASI 是擴大 Wasm 可能的範圍的關鍵促成因素之一，包括像下面即將提到的服務器端應用程序。

3.3 服務器端場景

雖然已經有很多例子證明了 Wasm 在客戶端的優勢和價值，但我們對 Wasm 在服務器端的想象空間更加興奮。Wasm 的每一個設計原則（速度、安全和可移植性）都能使下一波服務器端的工作負載成爲可能。

3.3.1 Serverless 計算

Serverless 強依賴高度優化的冷啓動，Wasm 運行時（如 WasmEdge）非常適合爲下一代無服務器平臺提供動力。SecondState、Cloudflare、Netlify 和 Vercel 等公司都支持通過其邊緣運行時部署 WebAssembly 功能。其他公司如 Grafbase 正在使用 Wasm，使開發者能夠在邊緣用他們選擇的語言編寫和部署 GraphQL 解析器。同時，Fermyon 提供了一個類似於 FaaS 的自助式開發平臺，用 Wasm 合成和運行基於雲的應用程序。

3.3.2 邊緣的數據分析和機器學習

Wasm 的效率和可移植性使其獨特地適合於支持邊緣的機器學習工作負載，部署在外形和計算能力差異很大的設備上。我們相信，實時 ML 用例將推動計算越來越接近數據產生的地方，無論是運行在網絡邊緣（如 CDN）還是設備邊緣（如 IoT）。Wasi-nn（神經網絡）是一個 API 規格，旨在將服務器端的 Wasm 程序與運行在主機上的流行 ML 框架（如 Tensorflow、PyTorch、OpenVINO）連接起來。 今天利用 Wasm 的 ML 場景的公司包括 Edge Impulse 和 Hammer of the Gods，前者提供一個低代碼開發平臺，將 TinyML 模型設計和部署到 Wasm 模塊中，在嵌入式設備上運行；後者使開發者能夠創建超便攜容器，通過其開源項目 Rune，使用 Rust 和 Wasm 在邊緣運行 ML 的工作負載。

3.3.3 插件和擴展

Wasm 的多語言支持和沙盒隔離技術使其成爲產品的有力的候選技術，產品開發者希望在現有的應用程序上提供一個可擴展的模型和執行第三方（可信或不可信）代碼的能力。例如，Shopify 在其 Shopify Scripts 框架背後使用了 WebAssembly，爲商家提供了以更有效的方式定製客戶體驗中對性能敏感的方面（如購物車、結賬）的能力。Suborbital 提供了一個擴展引擎，使 SaaS 供應商能夠安全、獨立地運行 "終端用戶開發者" 提供的代碼。Dynaboard 使開發者能夠在其低代碼網絡應用程序開發平臺之上運行用戶提供的代碼，包括客戶端和服務器端。

SingleStore 和 ScyllaDB 已經開始利用 Wasm，用用戶定義的函數（UDF）引擎來擴展他們的數據庫，允許開發人員重新使用現有的庫，並將計算轉移到數據庫本身（例如，規避了將數據導出到另一個應用程序進行處理的限制）。

同時，RedPanda 和 Infinyon 允許用戶使用 Wasm 對流媒體數據進行實時內聯轉換。  代理服務器領域也開始接受 Wasm，Tetrate（Sapphire Portfolio 公司）等服務網格供應商正在開發 func-e 等工具，以幫助團隊快速構建 Wasm 模塊，擴展開源的 Envoy。

Profian 是 Enarx 的監護人，這是一個開源項目，使用 Wasmtime 運行時間在可信執行環境（TEE）內執行 Wasm 二進制文件——這是 Wasm 的硬件可移植性的另一個場景。雖然 Wasm 的安全模型保護主機免受不受信任的代碼影響，但 Profian 將這一好處翻轉過來，在 TEE 內使用 Wasm 二進制文件，以保護應用程序免受不受信任的主機影響。這使企業能夠將其敏感的應用程序和數據部署到雲端或內部，並獲得加密保證。

3.3.4 Web3 應用開發和智能合約

Wasm 天然適合以加密爲中心的場景：首先 Wasm 的可移植性使運行不同硬件集的節點網絡具有可靠性；其次 Wasm 的性能在這些網絡中轉化爲更廣泛的效率。

Ewasm 是一個關鍵的例子，並被視爲以太坊第二階段升級的一個關鍵組成部分。Ewasm 將取代以太坊虛擬機（EVM），EVM 虛擬機目前爲交易提供動力並維護以太坊的網絡狀態，但沒有針對不同的硬件平臺進行優化，因此效率不高。Ewasm（連同分片和轉向股權證明）代表了改善整體網絡性能，並提供了一個更具擴展性的底層，爲希望建立去中心化應用程序的開發人員擴大了對 Solidity 以外的語言支持。

Wasm 也被用來支持其他網絡和可互操作區塊鏈的計算。例如，Parity 是 Substrate 的開發者，這是一個開源框架，使用 Wasm 作爲 Polkadot 生態系統的骨幹。同時，CosmWasm 是一個爲 Cosmos 生態系統建立的多鏈智能合約平臺，運行 Wasm 字節碼。Fluence 實驗室提供 Marine，這是一個通用的 Wasm 運行時，與他們的專用編程語言 Aqua 相結合，使分散的應用程序和協議能夠在他們的點對點網絡上運行。目前利用 Wasm 的其他協議包括 NEAR、Dfinity、EOS 等。

四、Wasm 的應用和基礎大圖

我們已經列出了一些公司和組織，他們主要分爲兩類：一類是使用 Wasm 來支持他們自己的產品和平臺；另一類是提供所需的基礎工具和基礎設施，使開發人員能夠自己建立 Wasm。

五、最後總結

5.1 Wasm 的未來

雖然我們看到許多初創企業和科技巨頭採用 Wasm 技術，但生態系統的一些關鍵技術只是在最近才逐漸發展起來。今天，Wasm 帶來增量效益往往被使用一個低級技術和一個不成熟的工具鏈所帶來的額外成本所抵銷。

我們認爲在推動 Wasm 的未來應用中有四個方面是最重要的。

• **無縫的****開發者體驗。**在最初階段，開發人員在企業級利用 Wasm 所需的環境一直是比較複雜的。Wasm 的開發者體驗並不舒適（例如，調試 Wasm 仍然是衆所周知的困難），在整個開發生命週期中，在編譯到 Wasm 和以實際方式利用 Wasm 方面，有大量的空間可以提供更好的工具。 同時大多數開發人員不具備低級語言和技術的專業知識，因此，通過抽象來提高可用性對促進更多的人的採用是非常重要的。我們已經開始看到第一波明確致力於爲開發者配備這些工具的公司，包括 Fermyon、Second State、Suborbital、Wasmer 和 Cosmonic。

• 標準的繼續推進。 雖然社區有一些分裂意見（例如，見 AssemblyScript 決定放棄對 WASI 的支持），但是 Wasm 標準的活力依然重要。除了蓬勃發展的創業生態系統，微軟、亞馬遜、谷歌、Fastly、Cloudflare、Mozilla 等科技巨頭也開始認識到 Wasm 是支持下一代雲工作負載的有效底層，他們正在積極爲標準機構和非營利組織（如 W3C 和字節碼聯盟）做出貢獻，以推動這個社區的發展。CNCF 也在發揮重要作用，接受 wasmCloud 和 WasmEdge 作爲沙盒項目。仍有重要的工作要做；像文檔，如垃圾收集、本地 DOM 訪問、套接字、線程、組件模型等，都在激烈討論中。標準的總體目標是使 Wasm 更適用於更多的目標，並適用於更多的使用案例。

• 編程語言支持。 雖然 Wasm 最常被吹捧的好處之一是多語言支持，但目前支持的現實狀態是介於兩者之間。像 C++、Go（包括 TinyGo）和 Rust 這樣的語言已經接受了 Wasm，但一些最常見的語言，如 Python、Java 和 PHP 還在努力實現一等公民的地位。 爲了真正實現主流採用，Wasm 的支持必須繼續擴展到一些更復雜的語言，如 C++ 和 Rust，並向最廣泛採用的語言擴展。 對於那些有興趣跟蹤這方面進展的人來說，Fermyon 團隊已經做了一項偉大的工作，即跟蹤 Wasm 在 RedMonk 的前 20 種編程語言中的支持情況。中國的 Gopher 創建的凹語言則將支持 WASM 作爲第一目的，其語言命名正是 Wasm 圖標基於中國漢字的變形。

• 理念、傳播和社區。  正如我們在容器和協調引擎（如 Kubernetes）的案例中看到的那樣，開發者對 Wasm 的採用可以通過佈道者和更廣泛的、成熟的倡導者社區來進一步推動。像雲原生計算基金會（CNCF）和字節碼聯盟這樣的組織已經走在了吸引開發者的前列，以促進對 Wasm 相關項目、活動和倡議的參與。除了開發者受衆，其他利益相關者對 Wasm 的認識可以通過闡述二階價值主張來推動，例如在雲和 Serverless 環境中使用 Wasm 可能帶來的成本節約。

5.2 Wasm 會取代容器嗎？

隨着時間的推移，我們相信 Wasm 運行時將作爲 containerd、microVMs（Firecracker）和其他流行的容器結構的合法替代品 - 特別是隨着 WASI 等標準的進一步擴展。這並不是說 Wasm 將全盤取代容器；在可預見的未來，它們將並肩存在，而利用每種容器的決定是由特定工作負載的特點所驅動的。

與傳統的基於管理程序的虛擬機相比，Docker 風格的容器提供了顯著的改進，而 Wasm 已經能夠將這些相同的效率提高到 "下一個水平"。憑藉其亞毫秒級的冷啓動，Wasm 容器非常適合壽命較短的無服務器和邊緣工作負載（除了現有的客戶端用例之外）。同時，傳統的 Docker 式工作負載非常適用於需要大量 I/O 或需要訪問網絡套接字的長期運行的服務（如緩存服務器）。

我們渴望看到像 Kubernetes 這樣的協調引擎如何隨着時間的推移與 Wasm 進行整合。儘管還很早，但像 Krustlet（kubelet 代理的替代品）、runwasi、Containerd Wasm Shims 和 crun 的 Wasm 處理程序等項目和擴展都旨在將 Wasm 提升爲容器環境中的一等公民，將其作爲一個新的運行時類，可以由 K8s 進行相應的調度和管理。

5.3 誰會贏？

雲廠商和 Serverless 是這裏的明顯候選人。但在 Sapphire 依然期望保持對 Wasm 生態每一個新興技術保持近距離的關注依然。

隨着任何新興技術的出現，需要使其能夠被主流採用。我們已經開始看到了許多真實的案例。然而，儘管今天正在推進的標準和正在開發的框架和運行時爲實現 Wasm 的潛力奠定了基礎，但百廢待興仍有許多工作要做。從以 Wasm 爲中心的應用開發到開發人員生產力工具，到監控和安全解決方案，我們很高興支持那些建立基礎設施和工具的人，爲每個人釋放 Wasm 的優勢，從個人開發者到全球企業。

如果你正在爲 Wasm 生態系統做出貢獻，或者正在使用 Wasm 爲你的基礎設施提供動力，請聯繫 anders@sapphireventures.com, liu@sapphireventures.com 或 carter@sapphireventures.com - 我們很樂意聽到你的意見！

特別感謝 Michael Yuan、Matt Butcher、Liam Randall、Connor Hicks 和 Alexander Gallego 的寶貴觀點和反饋。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/9SQeSYVSJ-R-tsiwex5KRQ