重新定義代理中的擴展性 - 將 WebAssembly 引入 Envoy 和 Istio

使用 WASM 的 Istio 擴展性未來。

2020 年 3 月 5 日 | 作者：Craig Box、Mandar Jog、John Plevyak、Louis Ryan、Piotr Sikora - Google，Yuval Kohavi、Scott Weiss - Solo.io

自 2016 年採用 Envoy 以來，Istio 專案一直希望提供一個平台，可以在此平台上建立豐富的擴充功能，以滿足我們用戶的多樣化需求。在服務網格的數據平面中新增功能有很多原因 — 為了支援較新的協定、與專有的安全控制整合，或使用自訂指標來增強可觀察性，僅舉幾例。

在過去的一年半中，我們 Google 的團隊一直在努力使用 WebAssembly 將動態擴展性新增到 Envoy 代理中。我們很高興今天與大家分享這項工作，並推出 用於代理的 WebAssembly (Wasm) (Proxy-Wasm)：一個 ABI，我們打算將其標準化；SDK；以及它的第一個主要實現，新的、低延遲的 Istio 遙測系統。

我們也與社群密切合作，以確保使用者能夠快速上手，獲得良好的開發人員體驗。Google 團隊一直與 Solo.io 的團隊密切合作，他們建立了 WebAssembly Hub，這是一項用於建立、分享、發現和部署 Wasm 擴充功能的服務。透過 WebAssembly Hub，Wasm 擴充功能可以像容器一樣輕鬆地進行管理、安裝和執行。

這項工作今天以 Alpha 版發布，還有很多 工作要做，但我們很高興將其交付給開發人員，以便他們可以開始體驗這項技術帶來的巨大可能性。

背景

對擴展性的需求一直是 Istio 和 Envoy 專案的創始原則，但這兩個專案採取了不同的方法。Istio 專案專注於啟用稱為 Mixer 的通用進程外擴展模型，並提供輕量級的開發人員體驗，而 Envoy 專注於代理內 擴充功能。

每種方法都有其優缺點。Istio 模型導致嚴重的資源效率低下，影響了尾部延遲和資源利用率。此模型也存在內在限制 — 例如，它永遠不會支援實作 自訂協定處理。

Envoy 模型強制執行單體建置流程，並要求使用 C++ 撰寫擴充功能，限制了開發人員的生態系統。向機群推出新的擴充功能需要推送新的二進位檔並進行滾動重新啟動，這很難協調，並且有停機的風險。這也鼓勵開發人員將僅由少數部署使用，但為了能夠搭上 Envoy 發布機制的便車，將擴充功能向上游合併到 Envoy 中。

隨著時間的推移，Istio 的一些對效能最敏感的功能已向上游合併到 Envoy 中 - 例如，流量上的原則檢查和 JWT 驗證。儘管如此，我們一直希望收斂到一個單一的擴充性堆疊，以減少權衡：一種將 Envoy 發布與其擴充功能生態系統分離的東西，使開發人員能夠以他們選擇的語言工作，並使 Istio 能夠可靠地推出新功能而不會有停機風險。這就是 WebAssembly 的用武之地。

什麼是 WebAssembly？

WebAssembly (Wasm) 是一種可攜式位元組碼格式，用於以接近原生速度執行以 多種語言撰寫的程式碼。它最初的 設計目標與上面概述的挑戰非常一致，並且背後有相當大的產業支援。Wasm 是第四種在所有主要瀏覽器中原生執行的標準語言（繼 HTML、CSS 和 JavaScript 之後），它在 2019 年 12 月成為 W3C 建議。這使我們有信心對其進行策略性押注。

雖然 WebAssembly 最初是作為用戶端技術而生的，但在伺服器上使用它有很多優點。執行階段具有記憶體安全性，並且會進行沙箱化以確保安全。有一個大型的工具生態系統，用於以文字或二進位格式編譯和偵錯 Wasm。W3C 和 BytecodeAlliance 已成為其他伺服器端工作的活躍中心。例如，Wasm 社群正在 W3C 標準化 「WebAssembly 系統介面」(WASI)，並提供了一個範例實作，它為 Wasm「程式」提供了類似 OS 的抽象。

將 WebAssembly 引入 Envoy

在過去 18 個月中，我們一直與 Envoy 社群合作，在 Envoy 中建構 Wasm 擴展性並向上游貢獻。我們很高興宣布它在隨 Istio 1.5 發布的 Envoy 建置中以 Alpha 版提供，原始碼位於 envoy-wasm 開發分支中，並且正在進行將其合併到 Envoy 主樹中的工作。此實作使用建置在 Google 高效能 V8 引擎中的 WebAssembly 執行階段。

除了底層執行階段之外，我們還建構了

使用 Wasm 擴展 Envoy 為我們帶來了幾個主要好處

「我非常高興看到 WASM 支援在 Envoy 中實現；這是 Envoy 擴展性的未來，完全停止。Envoy 的 WASM 支援與社群驅動的中心相結合，將在服務網格和 API 閘道用例的網路空間中釋放難以置信的創新。我迫不及待地想看看社群在未來會建構什麼。」– Matt Klein，Envoy 創作者。

有關實作的技術細節，請關注即將在 Envoy 部落格上發布的文章。

主機環境和擴充功能之間的 Proxy-Wasm 介面是刻意與代理無關的。我們已將其建置到 Envoy 中，但它被設計為由其他代理供應商採用。我們希望看到一個您可以將為 Istio 和 Envoy 撰寫的擴充功能，並在其他基礎架構中運行的世界；您很快就會聽到更多相關資訊。

在 Istio 中建構 WebAssembly

Istio 在 1.5 版本中將其幾個擴充功能移至其 Envoy 版本中，以便顯著提高效能。在執行這項工作的同時，我們一直在測試以確保這些相同的擴充功能可以編譯並作為 Proxy-Wasm 模組執行，而不會有行為上的差異。考慮到我們認為 Wasm 支援是 Alpha 版，我們尚未準備好將此設定設為預設設定；但是，這讓我們對我們的一般方法以及已開發的主機環境、ABI 和 SDK 充滿信心。

我們也仔細確保了 Istio 控制平面及其 Envoy 配置 API 能夠支援 Wasm。我們提供了範例，展示了如何執行幾個常見的客製化，例如自訂標頭解碼或程式化的路由，這些都是使用者常見的需求。當我們將此支援移至 Beta 版本時，您將看到說明如何將 Wasm 與 Istio 搭配使用的最佳實務文件。

最後，我們正與許多撰寫了 Mixer 轉接器 的供應商合作，協助他們遷移到 Wasm — 如果這是最佳的發展方向。Mixer 將在未來的版本中轉為社群專案，在那裡它將繼續可用於舊有的使用案例。

開發人員體驗

沒有良好的開發人員體驗，強大的工具也毫無用處。Solo.io 最近宣布 發布了 WebAssembly Hub，這是一組用於建置、部署、分享和探索 Envoy Proxy Wasm 擴充功能的工具和儲存庫，適用於 Envoy 和 Istio。

WebAssembly Hub 完全自動化了開發和部署 Wasm 擴充功能所需的許多步驟。使用 WebAssembly Hub 工具，使用者可以輕鬆地將他們的程式碼（以任何支援的語言）編譯成 Wasm 擴充功能。然後，這些擴充功能可以上傳到 Hub 註冊表，並透過單一指令部署和取消部署到 Istio。

在幕後，Hub 會處理許多細節，例如提取正確的工具鏈、ABI 版本驗證、權限控制等等。此工作流程還透過自動化擴充功能的部署，消除了 Istio 服務 Proxy 中配置變更的繁瑣工作。此工具可協助使用者和運營商避免因設定錯誤或版本不符而導致的意外行為。

WebAssembly Hub 工具提供強大的 CLI 以及優雅且易於使用的圖形使用者介面。WebAssembly Hub 的一個重要目標是簡化建置 Wasm 模組的體驗，並為開發人員提供一個分享和發現有用擴充功能的協作場所。

查看入門指南來建立您的第一個 Proxy-Wasm 擴充功能。

下一步

除了致力於 Beta 版本的發布之外，我們還致力於確保 Proxy-Wasm 周圍有一個持久的社群。ABI 需要定案，並在適當的標準組織內進行更廣泛的回饋，將其轉化為標準。將上游支援完成到 Envoy 主線的過程仍在進行中。我們也在為工具和 WebAssembly Hub 尋找合適的社群家園。

了解更多

分享這篇文章