mformat(mformation讀)

作者 | Tina、核子可樂

11 月 23 日，Wasmer 3.0 正式發布。作為開源WebAsmbly (Wasm) 開源運行時的最新版本，Wasmer 3.0 可以將 Wasm 編譯為適用于 Windows、Linux 或 Mac 的本機可執行文件，而無需任何運行時依賴。

創始人 Syrus Akbary 表示，新版本還能夠直接使用“wasmer run”運行 WAPM 包，這是一個新重建的 Rust API，并改進了對 WASI 的支持，它添加了文件 I/ O 和 WebAsmbly 的其他功能，用于在瀏覽器外運行。

Wasmer：從任何語言到任何操作系統

WebAsmbly 最初被設計為在 Web 瀏覽器中，以接近本機的性能，安全地運行以其他語言（例如 C/C++）編寫的代碼。2015 年，Luke Wagner 在自己的 Mozilla 博客上發布了一條公告：“我很高興向大家報告，我們在 Mozilla 開始跟 Chromium、Edge 和 WebKit 的工程師們合作創建新的標準——WebAsmbly。它定義了一種可移植，而且尺寸和加載效率更高的格式與執行模型，專供 Web 編譯場景使用。”

隨后，在 W3 的協助下，核心 Wasm 規范已經被列為“推薦”項目，且各大主流瀏覽器也都為其提供支持。并且多數語言都已經能夠支持 Wasm。Wasm 在瀏覽器領域取得了成功，也擁有了 Adobe 和 Figma 等體量可觀的采用者。但在此期間，Wasm 在瀏覽器之外的優勢也被越來越多的人所注意。對于 Wasmtime、Wamr、Wasm3、WasmEdge 和 Wasmer 等采用 Wasm 格式的非瀏覽器運行時，其一方面展示了 Wasm 規范的靈活性，比如把 Wasm3 當成解釋器來執行；另一方面則能支持 JIT 和 AOT 編譯，外加各種緩存及優化功能。

雖然 Wasm 在瀏覽器中高度依賴于 JavaScript 和 Wasm 運行時之間的橋梁，但非營利性組織字節碼聯盟（Cosmonic、Fermyon 和 Suborbital 等都是其成員）一起參與研發，希望為 Wasm 引入系統綁定。Wasm 系統接口（WASI）就是典型案例，其添加了能夠與文件系統、環境變量、時鐘和隨機數生成器等系統資源進行交互的標準化支持。

在這過程中，已經有很多人認為 Wasm 的未來就在于能在瀏覽器之外運行它。Fermyon 的 CEO Matt Butcher（軟件工程師、前教授，以及包含 Helm 在內的數十個開源項目的創始成員） 認為，Wasm 像虛擬機和容器一樣，能夠在云中運行，這才是真正令人興奮的地方。Wasm 代表了云原生技術的新時代，“我們喜歡容器。我們中的許多人多年來一直參與 Kubernetes 生態系統。但我們也很興奮，因為在容器生態系統中有些沒有解決的問題，現在我們正在找到解決方案。這就是為什么我們將其視為下一波浪潮。”

如今的新生標準已經讓 Wasm 能夠在瀏覽器之外發揮作用。很多 Wasm 項目的創建者/維護者對此感受非常積極：憑借著與瀏覽器高度匹配的各種特性，Wasm 在瀏覽器之外更有種“廣闊天地、大有作為”的意味。作為多個最大開源 Wasm 項目的創建者/維護者，Matt Butcher 等人發表了一篇技術博客，從多個積極的角度講解了為什么他們認為“Wasm 適用于瀏覽器，更適用于云”。

適用于瀏覽器，更適用于云

網絡瀏覽器中的語言運行時必須滿足幾大特征，而這些特征在云端也同樣非常重要。

安全性：如果要在瀏覽器中運行不受信代碼，則需要確保它是獨立運行的。這一點在云端也同樣適用。跨平臺/跨架構：當我們為瀏覽器構建代碼時，當然希望能一次編寫、隨處運行。這一點在云端也同樣適用。多語言：Wasm 項目的一大目標，就是將瀏覽器擴展到多種語言。云開發還不像瀏覽器開發那樣以 JS 為中心，所以多語言支持可以說是個必要前提。速度：沒人愿意坐等網頁加載，云端同樣如此。只有實現了即時加載，才能進行快速擴展。效率：瀏覽器在功耗方面需要控制好自己的“胃口”，云基礎設施也是一樣。運行時效率越高，運營成本也就越低。代碼大小：下載快慢，很大程度上取決于我們要下載怎樣的對象。較小的二進制文件下載得快，這類對象在云端也能夠更快移動。安全性

云軟件運行中的一大難題，就是了解其安全屬性、攻擊面和如何保障組織安全。當前供應鏈暴露出的安全漏洞以及未打補丁的遺留操作系統，已經給企業造成數十億美元損失和無法估量的業務時間拖延。

而 Wasm 的一大重要目標就是提供一個簡單、易于理解的表面區，確保代碼能夠在沙箱內執行，充分考慮到攻擊者從外而內或由內而外可能采取的一切基礎設施危害方法。Wasm 這種強制在沙箱內運行代碼、再與沙箱外操作系統交互的辦法，被具體拆分成了一個個精細的啟用選項。宏觀來看，我們可以在啟動時，將 Wasm 字節碼中所執行的每個“系統調用”都提供給運行時的一組函數處理。

如此一來，如果大家希望禁用文件系統訪問、網絡訪問、甚至是系統時鐘訪問，都可以隨時變更主機函數集來實現。再與具備邊界檢查的線性程序內存相結合，我們就得到了一個能夠執行任意不受信代碼的容器，其簡單性與攻擊面受控性都遠遠優于傳統的虛擬機和容器安全模型。

在現實世界中，這相當于是給操作人員提供一個能夠安定運行不受信代碼的執行環境。我們可以在這里測試未經審核的第三方依賴項，或者用戶提交的代碼（例如插件和用戶定義函數，簡稱 UDF）。對于用戶可以上傳軟件擴展代碼的情況，大家肯定不敢貿然把這些提交內容直接運行在基于容器的平臺上，畢竟其中還是有很大的內部基礎設施接觸和損害空間。

另外，我們還要考慮到用于執行用戶代碼的基礎容器鏡像可能包含漏洞，因此當需要對數百、數千甚至更多用戶提交的容器打補丁并進行操作系統重構時，這必然會造成巨大麻煩。通過從運行程序中刪除大部分“類操作系統”元素，Wasm 提供了一個更可控、更易于理解的底層基礎，幫助用戶在此之上構建起安全的代碼運行環境。

跨平臺/跨架構

Wasm 最受歡迎的特性，應該就是突出的平臺與架構中立性了。更重要的是，Wasm 的強大已經遠遠超出了 JVM 之類“一次編譯、隨處運行”的想象。這里我們以組件模型為例，其允許開發人員編寫代碼并將其 API 導出為接口。假設我們打算使用密鑰庫，而密鑰存儲的接口可能如下所示：

t: func(key: string, value: payload, ttl: option<u32>) -> expected<unit, error>

get: func(key: string) -> expected<payload, error>

delete: func(key: string) -> expected<unit, error>

如果我們想要實現一個密鑰庫，當然可以用任何語言來編寫（示例中使用的就是 Go），而且只要導出到這個接口，就能將其編譯成 Wasm 模塊。之后，另一位想要使用這個實現的開發者可以用另一種不同的語言編寫代碼，并繼續使用我們用 Go 編寫的鍵值實現。從本質上講，這就相當于提供了一個通用庫或依賴項注冊表，能夠根據各個具體用例的需要組合起來。因此，大家不必為每種語言建立單獨的客戶端庫，而是實現一次編寫、隨意“組合”。無論大家使用哪種語言、平臺或者架構，共享和協作都將變得輕松而順暢。

Matt Butcher 等人認為，除了 Wasm 的跨平臺/架構可組合性之外，它還特別適合在后 Kubernetes 時代下作為運行時方案。“我們知道這個觀點可能有點激進，但人們會很快意識到，Kubernetes 和容器技術的拓展邊界已經快到頭了。沒錯，我們總會說容器可以‘隨處運行’，但捫心自問，大家都知道這個結論有待商榷。為了支持不同的平臺，我們需要為每個平臺+架構組合構建不同的鏡像。此外，容器其實是一種 Linux 技術。沒錯，也有一些特別聰明的貢獻者讓 Windows 也獲得了容器，但這已經是套完全不同的技術方案了（無法直接運行 Linux 容器，常規容器平臺也沒法直接運行 Windows 容器）。”

另外，容器運行時的開銷并不小（特別是在 Kubernetes 的時候），所以很難在邊緣位置廣泛應用。最重要的一點，容器還需要不斷支持越來越多的定制化處理器。可以看到，Wasm 簡直堪稱完美的解決方案——它具備明顯的平臺和架構中立性，代碼體積小，代碼既可以直接運行在大型云服務器上、也能在邊緣位置的微型設備中起效，而且無需任何重新編譯。

Matt Butcher 等人承認容器在云過渡時期帶來的種種便利，但也堅持 Wasm 才代表著后 Kubernetes 時代的未來形態。

多語言支持

我們知道，Wasm 的另一大關鍵特性就是支持多種語言。由于 Wasm 代表一個編譯目標，所以只要你使用的語言支持 Wasm 就可以了。有些語言的 Wasm 支持來得較早，有些稍微晚些，但目前大部分語言都已經開始甚至完成了這項工作。總之，開發者可以用不同的語言編寫同一應用程序內的各個服務、甚至是各個部分。這就是組件模型的威力所在！

對此，Matt Butcher 等人再放豪言：“我們認為，Wasm 有可能會成為最后一種插件模型”。截至目前，為任何工具編寫插件都是種痛苦的體驗。大家要么必須使用相同的語言編寫，要么得設置某種通信協議（例如 gRPC），要么使用某種商定的 stdin/stdout 合約輸出二進制文件。這些選項局限性強、效率也不高。而使用 Wasm，插件可以用任意語言編寫、再編譯成 Wasm。之后，該 Wasm 模塊就能作為插件模型的一部分由任何其他語言執行——無需勞煩 shell、也不必跨進程通信。最重要的是，Wasm 還有速度和大小優勢。

速度

讓公有云成為可能的關鍵支持技術，其一是虛擬機，其二是容器。二者都是在計算世界中占有一席之地的偉大技術，但卻不可能是滿足一切云需求的至高“銀彈”。當在資源受限或者使用率極高（例如邊緣計算、物聯網或規模巨大的數據處理集群等場景）的條件下運行代碼時，虛擬機和容器其實會阻礙我們充分發掘硬件性能的能力。

而 Wasm 在多數情況下都能提供相同或更高的隔離保障，讓我們能夠安心剔除虛擬機和容器的底層“公有云安全網”，更好地使用運行代碼的服務器和設備。由于 Wasm 是一種低級字節碼，所以可以編譯并支持任何硬件架構、任何操作系統，因此我們完全能夠，也應該直接在裸機上運行 Wasm。這樣就能把工作負載更緊密地打包至可用硬件，并在性能、能源效率、環境影響等方面迎來新的飛躍。

這些性能優勢在云功能等臨時性工作負載中體現得尤其明顯。由于 Wasm 運行時及其加載的代碼，通常要比等效的容器鏡像或虛擬機小一個數量級（甚至更多），所以可以通過更高的復制量快速實現啟動和終止。在大部分云部署場景下，這些都是很重要的特性，能夠更靈活地部署軟件以應用流量高峰，進一步擴展來消化總流量波動。而且 Wasm 模塊實際上只是個程序，絕非操作系統中的容器或虛擬機，因此主機操作系統的控制和硬件優化機制也能高效利用多核心架構，同時繼續保持工作負載間的強隔離。

大小和效率

在目前的大部分用例中，我們其實都在過度消耗云資源。我們得準備充足的副本來滿足峰值負載要求，而這些副本在大多數時間里都處于閑置狀態，平白浪費資源。同樣的，由于我們需要針對超高需求進行優化，所以也得分配比必要水平更多的 CPU、內存和存儲空間，以便隨時應對流量高峰。承擔這么多浪費的理由只有一個：目前的解決方案無法實現快速擴展。

Wasm 的大小和效率優勢，讓快速擴展成為了可能。我們幾乎可以立即擴大規模，再輕松縮減回正常水平。我們可以在整個數據中心或集群內安裝同樣的小規模 Wasm 模塊，并在需求出現之前不實際執行。這樣，我們就能省下副本資源，保證只在必要時才把寶貴的資源拿出來。

而有了 JIT/AOT 運行時，我們還能對 Wasm 二進制文件進行執行預優化，進一步減少電力和資源消耗。

在多數場景下，需要處理的系統庫和文件工件數量也顯著減少，因此我們實際處理的對象大小要比容器時代小得多。

總而言之，所有這一切都指向了 Wasm 在云端的核心優勢：比其他云服務更低的運行成本。雖然 Wasm 還很年輕、還需要完善，但它提供的種種可能性已經非常有吸引力，如果社區發展更為壯大，Wasm 最終會發展出更美好的未來圖景。

參考鏈接：

https://wasmer.io/posts/announcing-wasmer-3.0

https://devclass.com/2022/11/25/wasmer-3-0-relead/

https://wasmer.io/posts/wasm-as-universal-binary-format-part-1-native-executables

https://thenewstack.io/whats-next-in-webasmbly/

https://www.wasm.builders/thomastaylor312/why-webasmbly-belongs-outside-the-browr-331a