WebAssembly現在和未來應用場景大全 - harshal

banq發表於2022-02-05
Web

WebAssembly（縮寫為 Wasm）是各種程式語言和許多不同執行環境之間的中間層。您可以獲取用 30 多種不同語言編寫的程式碼並將其編譯為 .wasm 檔案，然後可以在瀏覽器、伺服器甚至汽車上執行該檔案。
“WebAssembly”這個名稱具有誤導性。雖然它最初旨在使程式碼在 Web 上快速執行，但現在它也可以在瀏覽器之外的各種環境中執行。此外，WebAssembly 不是彙編，而是稍微高階一點的位元組碼。
 

WebAssembly 的優勢在哪裡？
WebAssembly 之所以出類拔萃，是因為以下五個特點：

  • 可移植性：Wasm 位元組碼的二進位制格式是標準化的，這意味著任何能夠執行 Wasm 的執行時都可以執行任何 Wasm 程式碼。1這類似於 Java 的“一次編寫，隨處執行”的承諾。在瀏覽器中，95% 的使用者瀏覽器都可以執行 WebAssembly，剩下的差距可以使用 wasm2js 編譯器來彌補。對於伺服器，有Wasmtime和Wasmer等執行時。即使是資源受限的物聯網裝置也可以使用WAMR加入樂趣。2
  • Universal統一：許多語言都可以編譯成 Wasm。這種支援超越了 C、C++ 和 Rust 等系統語言，包括垃圾收集的高階語言，如 Go、Python 和 Ruby。可以在此處找到編譯為 Wasm 的語言的完整列表。
  • “Near-Native 效能”：Wasm 通常被描述為具有“Near-Native 效能”。這實際上意味著 WebAssembly 幾乎總是比 JavaScript 快，尤其是對於計算密集型工作負載，並且平均比原生程式碼慢 1.45 到 1.55 倍，但結果確實因執行時而異。
  • 快速啟動時間：Wasm 的冷啟動時間非常重要，它保證了它自己的一個類別。在伺服器上，它可以實現比 Docker 容器快 10-100 倍的冷啟動，因為它不需要為每個容器建立新的 OS 程式。在瀏覽器中，解碼 Wasm 並將其轉換為機器程式碼比解析、解釋和最佳化 JavaScript 更快，因此 Wasm 程式碼可以比 JavaScript 更快地開始以最高效能執行。
  • 安全：WebAssembly 的設計考慮到了 Web，因此安全性是重中之重。在 Wasm 執行時中執行的程式碼是記憶體沙盒和功能受限的，這意味著它僅限於執行明確允許執行的操作。5在沙盒中，Wasm 程式碼仍然可以被授予訪問底層系統的許可權，包括系統級介面和硬體功能。

 

WebAssembly 在哪裡有用？
1. 加速 JavaScript
Wasm 及其前身 asm.js 背後的最初動機是加速 Web 上的客戶端程式碼，並且有很多 Wasm 在這個領域表現出色的例子：

  • 例如，Figma 設計工具的核心是用 C++ 編寫的，然後編譯為 WebAssembly。他們發現使用C++ 編寫在效能和可用性方面取得了重大優勢，同時[url=https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/]編譯為 WebAssembly[/url]將載入時間縮短了 3 倍，並顯著減少了下載大小。
  • 當切換到 Wasm 時，密碼管理器 1Password 在表單繁重的網站上實現了13-39 倍的加速。Wasm 效能也比 JavaScript更一致，這對於延遲敏感的應用程式很重要。

  
2. 程式語言互操作性
WebAssembly 讓我們更容易跨越程式語言之間的界限。庫和框架通常是用一種語言編寫的，這使得在不完全重寫的情況下很難使用其他語言的程式碼。使用 WebAssembly，我們可以更輕鬆地執行用其他語言編寫的程式碼。這使我們能夠重用程式碼，而不是重新發明輪子。
目前，這主要用於將應用程式移植到網路上。這裡有一些例子：
  • Figma 使用名為 Skia 的低階 C++ 庫來處理一些圖形演算法，而不是構建自己的演算法或將它們移植到 JavaScript。
  • 我最喜歡的國際象棋伺服器 lichess.org 在使用者的瀏覽器中執行世界級的 Stockfish 國際象棋引擎，從而為他們節省了在伺服器端執行它的計算負擔。
  • Google Earth和Adobe Photoshop使用 Wasm 將他們的 C++ 程式碼庫移植到了網路上。

將應用程式移植到 Web 是最容易開始的地方，而且我們很可能會看到這種趨勢繼續下去。但是，Wasm 的互操作性不僅限於瀏覽器。它還被用於使程式碼跨平臺和跨裝置工作：
  • Uno 平臺是一個 UI 平臺，可讓您編寫單個應用程式並讓它在 Windows、macOS、iOS、Android、Linux 和瀏覽器上執行。它似乎相當以 Windows 為中心，因為應用程式是用 C# 和 XAML 編寫的，因此許多用例都基於減少將舊應用程式移植到新平臺所需的工作量。
  • Amazon Prime、Disney+和BBC都在其影片平臺中使用 WebAssembly。例如，Amazon Prime 使用它為各種裝置型別提供新功能，同時保持可接受的效能。

除了應用程式的可移植性之外，WebAssembly 還可以充當伺服器端的跨語言橋樑。不幸的是，我們還沒有看到太多這樣的情況，因為用於與作業系統通訊的介面（Web Assembly System Interface，縮寫為 WASI）和跨語言邊界工作（Wasm 元件模型）仍在開發中，還沒有尚未達到必要的成熟度水平。
 
3.外掛系統
當大多數應用程式達到一定程度的成熟度時，它們需要允許終端使用者進行擴充套件。從歷史上看，應用程式已經達到了豐富的配置系統或構建複雜的 DSL，但這些總是被證明是非常痛苦的管理或迫使開發人員使用不熟悉的語言工作。
我們來看一個例子：在像 NGINX 這樣的系統中配置請求過濾規則。為此，系統管理員必須以他們不熟悉的自定義配置語言以宣告方式實現所需的邏輯。他們受制於 NGINX 設計者預期的匹配和過濾運算子型別，這通常嚴重限制了他們實現所需行為的能力。如果出現任何問題，由於缺乏可用的工具，除錯可能會令人沮喪。
一些較新的應用程式選擇了不同的方法：提供一組標準介面並嵌入 Wasm 執行時，並讓終端使用者提供實現所需自定義邏輯的 Wasm 二進位制檔案。這為終端使用者提供了一個更加靈活和熟悉的介面：他們可以實現任意複雜的業務邏輯，並且可以使用他們選擇的任何語言來實現。出於安全考慮，這在其他語言中是不可能的，但 Wasm 使它變得可行，因為執行時可以沙箱化使用者提供的程式碼。
今天使用的幾個例子：
  • Envoy 代理最初由 Lyft 開發，現在在整個行業中使用，它允許使用 Wasm 構建擴充套件並在執行時動態載入。建立在 Envoy 之上的 Istio 服務網格也緊隨其後。
  • Redpanda 是 Kafka 的替代品，允許使用者使用 Wasm 編寫流內自定義資料轉換。
  • Open Policy Agent 允許使用 Wasm 定義策略。
  • Minecraft 伺服器Feather使用 WebAssembly 在沙箱中執行外掛。

 
4. 嵌入式沙盒
將 WebAssembly 嵌入到其他應用程式中的想法在外掛系統之外很有用。事實上，它可用於沙箱整個第三方庫或為第一方程式碼構建安全層。
Firefox透過保護自己免受第三方庫中的錯誤（例如用於拼寫檢查或影像解碼的庫）在這一領域處於領先地位。結合一個名為 RLBox 的工具，它提供了一個汙染層，它們可以防止這些庫中的漏洞，而無需求助於嚴格的程式隔離。對於 Firefox，他們甚至沒有在最終版本中釋出 Wasm 二進位制檔案。編譯成 Wasm 然後轉譯成另一種語言的過程，再加上 RLBox，提供了他們需要的安全性。
這種方法可能會阻止一些嚴重的漏洞被利用。由於攻擊者通常將多個漏洞連結在一起，因此此類中間安全層可能會非常寶貴。
 
5. 容器化
在一條經常被引用的推文中，Docker 創始人 Solomon Hykes 強調了 WebAssembly 的重要性：
如果 WASM+WASI 在 2008 年存在，我們就不需要建立 Docker。這就是它的重要性。伺服器上的 Webassembly 是計算的未來。
有充分的理由相信 Wasm 代表了容器化的未來。與 Docker 相比，它的冷啟動時間快了 10-100 倍，佔用空間更小，並使用了更好的基於能力的約束安全模型。使 Wasm 模組（而不是容器）成為計算和部署的標準單元將實現更好的可擴充套件性和安全性。
這種轉變不會在一夜之間發生，因此基於 Wasm 的容器化可能會整合到現有的編排系統中，而不是試圖完全取代 Docker。
我預計這個空間將在未來幾年內充滿活力。一些專案已經處於領先地位：
  • Microsoft Azure 的 Deis Labs 構建了 Krustlet，這是一種在現有 Kubernetes 叢集中執行 Wasm 工作負載的方法。
  • Deis Labs 還發布了Hippo，一個以 Wasm 為中心的平臺即服務。我猜Fermyon正試圖將這項技術商業化。
  • 透過他們的wasmCloud專案，Cosmonic正在構建一個平臺和編排層，將 Wasm 容器化與分散式系統的參與者模型相結合。
  • Lunatic平臺還包含 Actor 模型，並且似乎具有在單個 WebAssembly 執行時程式之上執行多個輕容器的最佳支援。
  • Suborbital的Atmo是另一個平臺和編排系統，但更面向無伺服器工作負載。

 
6. FaaS/無伺服器平臺
功能即服務平臺需要快速安全地執行使用者提供的程式碼。由於無伺服器平臺通常用於短時間執行程式碼，因此啟動時間是一個特別重要的指標。超快的冷啟動和廣泛的語言支援使 Wasm 成為無伺服器工作負載的理想選擇。

Cloudflare Workers和Fastly Compute@Edge提供的 CDN 邊緣計算平臺已經提供了執行 WebAssembly 的能力。Fastly 聲稱啟動時間比市場上的其他產品快 100 倍，並將這種加速歸功於他們基於 WebAssembly 的編譯器和執行時。Netlify 和 Vercel 也在這個領域構建產品。
主要雲提供商構建的無伺服器平臺也不甘落後：AWS Lambda 幾個月前推出了 WebAssembly 無伺服器功能，我預計 GCP 和 Azure 也會效仿。
 
7.區塊鏈
以太坊和 Solana 等平臺為使用者編寫程式碼提供了一種機制，稱為“智慧合約”，可以在區塊鏈上執行。以太坊構建了一個完全定製的系統，建立了一種名為 Solidity 的語言，一種用於編譯位元組碼的二進位制格式，以及用於沙盒執行的以太坊虛擬機器。Solana 選擇重用一些現有的創新，利用 LLVM 編譯器基礎架構將 C、C++ 或 Rust 程式碼編譯為受伯克利包過濾器啟發的二進位制位元組碼格式，但仍然構建了自己的執行時，稱為 Sealevel。
WebAssembly 已經提供了很多這樣的基礎設施：它允許使用者用他們選擇的語言編寫程式碼，提供編譯器基礎設施來生成 Wasm 位元組碼，並具有許多高效能執行時。
但是如果以太坊和 Solana 已經構建了這個基礎設施，那麼 WebAssembly 提供了什麼價值呢？主要的增值實際上是圍繞生態系統。例如，以太坊有自己的智慧合約編寫語言，這意味著它無法利用其他語言編寫的所有庫和常用函式。Solana 好一點，因為它可以使用 Rust 生態系統。假設可以克服技術挑戰，WebAssembly 向更廣泛的受眾開放智慧合約開發，並使他們能夠使用他們已經熟悉的庫和工具。
我絕對不是第一個意識到這一點的人。例如，Polkadot 網路使用基於WebAssembly 的虛擬機器作為其執行時。EOS 虛擬機器也是基於 WebAssembly 的。CosmWasm使用它來構建跨多個區塊鏈工作的智慧合約。還有一個名為eWASM的提議，用 WebAssembly 的有限子集取代以太坊虛擬機器，但似乎這項努力已經失敗了。Wasmer 執行時提供了一種明確為區塊鏈構建的“單通道”編譯器模式，而 WasmEdge 聲稱擁有與以太坊相容的智慧合約執行引擎。
 

預測和機會
1. 一種新的應用架構
正如 Docker 無法完全替代虛擬機器一樣，Wasm 也無法完全替代 Docker。例如，Docker 容器不能執行自定義作業系統核心，而虛擬機器可以。同樣，Wasm 容器不能使用一些專門的 CPU 指令，例如 x86 的 256 位 AVX 指令9，因此在某些應用程式的效能上無法與 Docker 競爭。
在我看來，Docker 可以支援但 Wasm 不能支援的工作負載集目前大於 Docker 和虛擬機器之間的類似增量。然而，Wasm 仍然是一項發展中的技術，因此將逐漸能夠處理更多型別的工作負載。Docker 的興起與微服務架構的興起密切相關。這採用了非常適合虛擬機器的單體應用程式，並將其替換為非常適合 Docker 容器的微服務。我們可能會看到一種利用 WebAssembly 獨特功能的新應用程式架構。
根據康威定律，應用程式的架構反映了產生它的組織的通訊結構。計算歷史上每一個新的“參考架構”都減少了人與人之間所需的協調量。從大型機到虛擬機器再到 Docker 容器，生產可部署單元所需的人數逐漸減少。我們透過將系統分解成越來越小的元件並允許構建這些元件的人員獨立於定義良好的介面工作來實現這一點。雖然微服務已經將單體應用程式分解成幾個小的獨立服務，但 WebAssembly 使將微服務分解成更小的元件變得更加容易。
這會是什麼樣子？這裡有幾種可能性：

  • 當您將應用程式拆分為核心業務邏輯和與其他系統一起工作所需的膠水程式碼時，事實證明，與其他系統相比，業務邏輯通常非常小。透過將膠水程式碼的介面與其提供的功能的實現分離，可以構建以業務邏輯為中心的應用程式並將其餘部分委託給外部功能提供者。再加上長期靠邊站的Actor模型，這就是wasmCloud做法的精髓。
  • 另一種可能性是，無伺服器架構是超越微服務的下一步。大多數服務可以分為有狀態和無狀態部分，無狀態部分可以作為任意可擴充套件的無伺服器功能執行。在這種情況下，WebAssembly 為那些無伺服器功能提供了方便且易於擴充套件的執行時。
  • WebAssembly 可能會改變我們處理第三方依賴項的方式。現代程式碼嚴重依賴第三方庫，11並且這些依賴項中的大多數都沒有經過全面或頻繁的審查。隨著最近的Log4j 漏洞等軟體供應鏈問題的曝光，我預計人們將開始更加重視第三方庫的安全性。像 Firefox 使用 Wasm 和 RLBox 來隔離某些庫的方法將變得更加普遍。假設可以克服效能限制，將第三方庫隔離到同一 Wasm 執行時內的單獨功能受限容器中也是可行的。

 
2. 棕地部署
Wasm 最終將需要以某種方式與 Docker 進行互操作。在接下來的幾年裡，這並不是絕對必要的，因為 Wasm 將主要用於綠地部署，對向後相容性的要求很少。但最終，Wasm 的棕地部署需要很容易才能完全贏得容器化競賽，尤其是在企業環境中。
一個潛在的結果是 Docker 將整合 Wasm 執行時。雖然看似合理，但我預計 Wasm 將有足夠的差異化，以保證完全獨立的工具。相反，Docker 和 Wasm 容器的統一將發生在編排層。
Kubernetes 是否會有效地整合基於 Wasm 的執行，或者是否會出現新的編排系統，目前尚不清楚。一方面，Kubernetes 目前是無可匹敵的編排之王。它具有令人難以置信的勢頭，Wasm 集裝箱化運動將是明智的選擇。微軟的人們正在透過構建Krustlet來投資這個未來，它允許您在 Kubernetes 中執行 Wasm 工作負載。另一方面，Wasm 程式碼與 Docker 容器有不同的要求，因此 Kubernetes 可能不適合。例如，在使用基於 Wasm 的第三方庫隔離時，為容器間通訊設定共享記憶體會很有用，這在 Kubernetes 中很難做到。這樣的 Wasm-native 編排器最終將構建橋樑，以簡化從 Docker 遷移或與 Docker 的整合。
雖然我對即將到來的 Wasm 編排器浪潮充滿希望，但 Kubernetes 已經足夠穩固，短期內它可能不會有任何進展。
 
3. 標準化的無伺服器/邊緣框架
大多數無伺服器提供商都有自己的框架來定義路由和 lambda 函式。例如，Cloudflare 定義了自己的“cf”型別，並提供了一個名為 wrangler 的 CLI 工具來設定程式碼腳手架。Fastly 有自己的一組介面用於與快取和日誌互動，AWS Lambda 也有類似的設定。Kubernetes 的 Fission 框架有自己的一組庫，用於與各種語言整合。一些平臺試圖透過讓使用者提供 Docker 容器來規避這個問題，這樣平臺只需要處理執行。Knative和Fly.io都遵循這種方法。然而，他們必須保持一個“暖池”的工作人員來減少冷啟動時間的影響，或者將這個問題傳遞給他們的使用者。
有機會構建標準化的無伺服器功能定義和部署規範。流行的無伺服器框架在抽象部署方面做得不錯，但仍將特定於提供程式的細節洩漏到功能實現中。一旦這些細節被抽象出來，多雲部署就變得更加容易，因此框架變得更加強大。它最終可能會像無伺服器的 Terraform。
 
4. 包管理
每種程式語言都有一個圍繞它的生態系統。大多數現代語言都有一個集中的包登錄檔：Python 有 PyPI，NodeJS 有 npm，Rust 有 Crates.io。此類登錄檔以及伴隨它們的工具和工作流程對於開發高質量的生態系統非常重要，並使開發人員的生活更加輕鬆。
對於 Wasm，WebAssembly 包管理器(WAPM) 承諾填補這一空白。然而，在實踐中，該專案似乎在很大程度上處於休眠狀態。在撰寫本文時，過去兩個月只更新了三個包。問題是軟體包應該相互構建，但 WAPM 僅適用於沒有相互依賴關係的獨立 Wasm 二進位制檔案。開發人員的另一個選擇是將 Wasm 模組釋出到 npm，但這當然不適合在 JavaScript 或 AssemblyScript 之外構建 Wasm 生態系統，因為它不鼓勵跨語言互操作性。
這個問題實際上並不是 WAPM 或 npm 的錯，而是 WebAssembly 本身的問題。

這正是 WebAssembly 元件模型要解決的問題。Wasm 元件標準化了 WebAssembly 介面格式，併為實現和使用這些介面提供了程式碼生成器。換句話說，它讓我們可以使用 Wasm 輕鬆跨越執行時和語言邊界。
為 WebAssembly 構建一個高質量的包管理器是一個很大的機會。它應該使用 Wasm 元件 codegen 來生成使用其他語言的 Wasm 模組的繫結。如果工具足夠好，它可以使跨語言開發變得輕而易舉，這將是伺服器端 WebAssembly 生態系統的真正解鎖。Wasm 包登錄檔甚至可以跨其他包登錄檔聯合，自動釋出具有適當生成繫結到 PyPI、npm 和 Crates.io 的包。
 

結論
此時你可能在想：如果 WebAssembly 這麼好，為什麼沒有得到更廣泛的使用？讓我自願做出一些回應：

  • WebAssembly 的營銷並不好。這個名字用詞不當，因為它既不限於網路也不是彙編。WebAssembly 主要面向 Web 開發人員進行營銷和推廣，但其真正的潛力在於瀏覽器之外。當 C++ 和 Rust 開發人員集體開始認識到 Wasm 所擁有的潛力時，真正的解鎖將會到來。
  • WebAssembly 標準化還不存在。例如，WebAssembly 系統介面有許多尚未正式標準化的擴充套件，但各種執行時實現了這些擴充套件的選擇。普遍可移植性的承諾尚未完全實現。
  • 跨語言互動很糟糕。在人們真正開始跨不同語言使用 Wasm 之前，我們需要 WebAssembly 元件和優秀的程式碼生成器來支援大量語言。
  • 開發人員的體驗還有很多不足之處。我希望看到工具方面的改進，尤其是在除錯方面，以及與包管理器、構建系統和 IDE 的整合。
  • 我不想這麼說，但在 WebAssembly 的庫隔離功能得到充分認可之前，我們可能需要一些更嚴重的軟體供應鏈事件，其規模與 Log4Shell 相似。

WebAssembly 已經部署在相當多的地方，並服務於各種各樣的用例，但這些代表了更廣泛的科技世界中孤立的活動領域。在我的朋友中，聽說過 WebAssembly 的一小部分人認為它在原則上非常令人興奮，但由於它還不夠成熟，所以沒有使用它進行構建。但是，其中許多問題正在積極處理中，並且可能會在未來一兩年內達到可接受的狀態。因此，我們似乎正處於 WebAssembly 活動、生態系統和社群爆發的邊緣。

 

相關文章