WebAssembly--雲原生項目可擴展性的利器

儘管在誕生之初，WebAssembly（簡稱Wasm）目的是爲瀏覽器帶來高級編程的功能 -- 它提供了一條途徑，以使得以各類語言編寫的代碼均可以以接近原生的速度在Web中運行。在這種狀況下，之前沒法以此方式運行的客戶端軟件都將能夠運行在Web中。

可是隨着最近幾年的發展，Wasm 憑藉着如下幾個特性：

1. 接近原生性能運行
2. 沙箱
3. 可移植性，build once， run everywhere

給雲原生項目帶來了可擴展性。

接下來咱們經過幾個雲原生項目，來看看Wasm 是如何成爲可擴展性的利器。

Envoy 和 Istio

Envoy是專爲大型現代服務架構設計的L7代理和通訊總線。其已經成爲了Service Mesh 解決方案數據面事實上的標準。

可是咱們在應用Envoy的過程當中，咱們可能但願插入其餘業務邏輯，例如度量，可觀察性，轉換，數據丟失預防，合規性驗證或其餘功能。

不過編寫和添加自定義Envoy模塊有點繁瑣。你必須使用C++編程並在Envoy中從新編譯。

爲了解決這個問題，Envoy 社區在 Envoy 中嵌入了 WASM 虛擬機以得到一個安全的沙箱環境，用於動態加載和運行可拔插的擴展代碼（被編譯爲 WASM 字節碼），簡化 Envoy 二次開發和功能加強的複雜度。

使用 Wasm 擴展 Envoy 帶來了幾個主要好處：

• 敏捷性：能夠用控制平面在運行時下發和重載擴展。這就能夠快速的進行擴展開發→ 測試→ 發佈週期，而無需重啓 Envoy。
• 可靠性和隔離性：擴展部署在具備資源限制的沙箱中，這意味着它們如今能夠崩潰或泄漏內存，但不會讓整個 Envoy 掛掉。CPU 和內存使用率也能夠受到限制。
• 安全性：沙盒具備一個明肯定義的 API，用於和 Envoy 通訊，所以擴展只能訪問和修改連接或者請求中有限數量的屬性。此外，因爲 Envoy 協調整個交互，所以它能夠隱藏或清除擴展中的敏感信息（例如，HTTP 頭中的 「Authorization」和「Cookie」，或者客戶端的 IP 地址）。
• 靈活性：能夠將超過 30 種編程語言編譯爲 WebAssembly，可讓各類技術背景的開發人員均可以用他們選擇的語言來編寫 Envoy 擴展，好比：C++，Go，Rust，Java，TypeScript 等。

在Envoy支持Wasm以後，istio也經過這種擴展機制，移除了Mixer組件，將現有的 out-of-process 的插件模型最終用基於 WASM 的 in-proxy 擴展模型來替代，極大提高了網格的性能。

OPA

Open Policy Agent（簡稱OPA）是一種開放源代碼的通用策略引擎，它統一了整個技術棧中的策略執行。 OPA背後的原則之一是策略評估與策略執行解耦。

在 OPA v0.15.1以前，各類基礎設施須要嵌入策略評估引擎。

因爲OPA策略評估引擎是使用golang編寫，因此對於其餘編程語言，集成OPA存在必定難度。其餘語言只能經過Restfull API的方式。

在OPA v0.15.1+版本，OPA 引入了Wasm來解決該問題。OPA包含一個接受Rego策略做爲輸入並生成可執行的Wasm程序做爲輸出的編譯器。該Wasm程序能夠加載到任何標準的Wasm運行時中，並在須要策略決策時執行。

容器 和 Kubernetes

隨着Wasm的發展，WebAssembly system interface（簡稱Wasi）出現了。WASI表明WebAssembly系統接口。這是由Wasmtime項目設計的API，可提供對幾種相似操做系統的功能的訪問，包括文件和文件系統，Berkeley套接字，時鐘和隨機數。

此時Wasm的沙箱機制帶來的隔離性和安全性，都比Docker作的更好。Docker的創始人也曾說過:"若是WASM + WASI在2008年存在，咱們就不須要建立Docker。"

用於建立能夠與容器相同的方式運行的有效二進制可執行文件。Wasm有潛力成爲Docker的重要替代部署單元。

Wasm container 與 Kubernetes的集成，目前有兩種思路：

Krustlet

Krustlet是一個用 Rust 開發的開源 Kubernetes kubelet，用於在 Kubernetes 中運行 WebAssembly 工做負載。

目前這是一個實驗性質的項目。

container-shim-wasm

該思路相對Krustlet，更加合理，侵入性也比較小。咱們只須要實現container-shim-wasm，使containerd直接能夠管理 Wasm container。

該方案與kata，firecracker集成Kubernetes 的實現思路都比較相似。

相信隨着Wasi的完善，咱們不久的未來，在kubernetes中，能夠經過RuntimeClass指定，在node節點運行Wasm container。

Serverless

其實截止目前，已經有大量的組織將Wasm用於serverless的場景。好比：

Second State提供了一個開源WebAssembly實現（Second State Virtual Machine，或SSVM），該實現專門針對服務器端應用程序進行了優化。它是

• 同類最佳的性能。對於冷啓動，它比Docker快1000倍。
• 無縫支持服務器應用程序框架，例如Node.js。您可使用SSVM構建高性能的Node.js應用程序。
• 支持安全訪問外部資源，例如數據庫，消息隊列，甚至是新的AI硬件
• 容許精確計量無服務器應用程序的計算資源。

Second State 已經支持Wasm用於AI，區塊鏈等場景。

而Cloudflare也早已推出了本身的Serverless 產品 Cloudflare Workers。

邊緣計算

邊緣運行的物聯網設備正在推進計算的將來，這已不是什麼祕密。可是，許多設備缺乏最佳的計算硬件或其餘資源，例如電源，網絡和存儲。

如今諸多基於Kubernetes的邊緣計算解決方案(kubeedge等），其邊緣工做運行時依舊是docker。這種作法不是最理想的，尤爲是對於物聯網和邊緣計算用例。

咱們是否能夠在邊緣端直接運行Wasm哪？

隨着Wasm通用運行時wasmer 1.0 GA，其推出了Headless版本。該版本提供儘量輕量級的執行環境，這對於在邊緣的IoT設備上高效運行Wasm相當重要。

藉助對AOT編譯的新增支持，咱們能夠運行「headless」版本的Wasmer，其重量僅爲數百KB，而且能夠在任何設備上運行任何預編譯的Wasm二進制文件。

總結

Wasm已經成爲了雲原生項目的擴展利器，而且很是有可能成爲雲原生工做負載的最佳運行時。