如何分析Envoy和Istio中的WebAssembly應用

今天就跟大家聊聊有關如何分析Envoy和Istio中的WebAssembly應用，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

自 2016 年使用 Envoy 以后，Istio 項目一直想提供一個平臺，在此平臺上可以構建豐富的擴展，以滿足用戶多樣化的需求。有很多要向服務網格的數據平面增加功能的理由 — 比如：支持更新的協議，與專有安全控件集成，或是通過自定義度量來增強可觀察性。

在過去的一年半中，我們在Google的團隊一直在努力用 WebAssembly 來為 Envoy 代理添加動態擴展。今天我們很高興與大家分享這項工作，并推出 針對代理的 WebAssembly (Wasm) (Proxy-Wasm)：包括一個會標準化的ABI，SDK，以及它的第一個重點實現：新的，低延遲的 Istio 遙測系統。

我們還與社區緊密合作，以確保為用戶提供良好的開發者體驗，幫助他們快速上手。 Google 團隊一直與 Solo.io 團隊緊密合作，Solo 他們已經建立了 WebAssembly Hub 服務，用于構建，共享，發現和部署 Wasm 擴展。 有了 WebAssembly Hub，Wasm 擴展就會像容器一樣易于管理，安裝和運行。

這個項目現在發布了 Alpha 版本，仍然還有很多工作要做，但是我們很高興將其交提供給開發者，以便他們可以開始嘗試由此帶來的巨大可能性。

背景

可擴展需求一直都是 Istio 和 Envoy 項目的基本原則，但是兩個項目采用了不同的實現方式。Istio 項目的做法是啟用一個通用的進程外擴展模型，叫做 Mixer，以此帶來輕量級的開發者體驗，而 Envoy 則專注于代理內擴展。

每種方法都各有利弊。Istio 模型導致明顯的資源效率低下，從而影響了尾部延遲和資源利用率。該模型在根本上來說是有局限性的 - 例如，它永遠不會支持實現自定義協議處理。

Envoy 模型強化了單體構建過程，并要求使用 C++ 編寫擴展，從而限制了開發者的生態。給集群發布新的擴展需要下發新的二進制文件并滾動重啟，這可能很難協調，并有可能會導致停機。這也促使了開發者向 Envoy 上游提交他們的擴展，而這些擴展僅由一小部分生產環境使用，更多僅僅是為了利用其發布機制。

隨著時間的流逝，Istio 的一些對性能最敏感的功能已合進了上游的 Envoy - 例如流量檢查策略和例如遙測上報。盡管如此，我們一直想把擴展匯聚在一個技術棧上，從而減少兩者之間猶豫折衷：這使 Envoy 版本與其擴展生態系統脫鉤，使開發者能夠使用他們選擇的語言進行工作，并使 Istio 可靠地推出新功能而不必有停機風險。

什么是 WebAssembly

WebAssembly（Wasm）是一種由多種語言編寫的，可移植的字節碼格式，它能以以接近本機的速度執行。其最初的設計目標與上述挑戰很相符，并且在其背后得到了相當大的行業支持。Wasm 是在所有主流瀏覽器中可以本地運行的第四種標準語言（繼HTML，CSS 和 JavaScript 之后），于 2019 年 12 月成為 W3C 正式建議。這使我們有信心對其進行戰略下注。

盡管 WebAssembly 最初是作為客戶端技術而誕生，但它在服務器上用也有很多優勢。運行時是內存安全的，并且以沙盒方式運行以確保安全。它有一個很大的工具生態系統，用于以文本或二進制格式編譯和調試 Wasm。W3C 和 BytecodeAlliance 已成為其它服務器端工作的活躍中心。比如，Wasm 社區正在 W3C 中標準化 “WebAssembly 系統接口 Interface” (WASI)，并通過一個示例實現，它為 Wasm “程序” 提供了一個類似 OS 的抽象。

把 WebAssembly 引入 Envoy

在過去的18個月中，我們一直與 Envoy 社區合作把 Wasm 的擴展引入 Envoy，并其貢獻到上游。我們很高興地宣布，此特性在 Istio 1.5 中帶的 Envoy 中以 Alpha 版本可用了，其源代碼在envoy-wasm 開發分支中，并且正在努力將其合并到 Envoy 主干上。該實現使用了 Google 高性能 V8 引擎 中內置的 WebAssembly 運行時。

除了構建底層的運行時，我們還構建了：

• 把 Wasm 嵌入代理的通用應用程序二進制接口（ABI），這意味著編譯后的擴展將可以在不同版本的 Envoy 中工作，甚至其它代理也可以，當然他們應該實現了前面的 ABI應

• 用 C++, Rust 和 AssemblyScript 可以方便進行擴展開發的 SDK，后續還有很多語言支持

• 全面的示例和說明介紹如何在 Istio 和獨立的 Envoy 中部署

• 允許使用其它 Wasm 運行時的抽象，包括把本地把擴展直接編譯進 Envoy 中 “null” 運行時，這對于測試和調試非常有用

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

• 敏捷性：可以用 Istio 控制平面在運行時下發和重載擴展。這就可以快速的進行擴展開發→測試→發布周期，而無需重啟 Envoy。

• 發布庫：一旦完成合并到主樹中之后，Istio 和其它程序將能夠使用 Envoy 的發布庫，而不是自己構建。這也方便 Envoy 社區遷移某些內置擴展到這個模型，從而減少他們的工作。

• 可靠性和隔離性：擴展部署在具有資源限制的沙箱中，這意味著它們現在可以崩潰或泄漏內存，但不會讓整個 Envoy 掛掉。CPU 和內存使用率也可以受到限制。

• 安全性：沙盒具有一個明確定義的 API，用于和 Envoy 通信，因此擴展只能訪問和修改鏈接或者請求中有限數量的屬性。此外，由于 Envoy 協調整個交互，因此它可以隱藏或清除擴展中的敏感信息（例如，HTTP 頭中的 “Authorization”和“Cookie”，或者客戶端的 IP 地址）。

• 靈活性：可以將超過 30 種編程語言編譯為 WebAssembly，可以讓各種技術背景的開發人員都可以用他們選擇的語言來編寫 Envoy 擴展，比如：C++，Go，Rust，Java，TypeScript 等。

“看到 Envoy 上支持了 WASM，我感到非常興奮；這是 Envoy 可擴展的未來。Envoy 的 WASM 支持與社區驅動的 hub 相結合，將在服務網格和 API 網關用例中開啟出令人難以置信的網絡創新。我迫不及待地想看到社區構建的向前發展。” – Envoy 創造者 Matt Klein。

有關實現的技術細節，請關注即將在 Envoy 博客上發的文章。

主機環境和擴展之間的 Proxy-Wasm接口有意設計為代理無感知的。我們已將其內置到了 Envoy 中，但它是為其它代理供應商設計的。我們希望看為 Istio 和 Envoy 編寫的擴展也可以在其它基礎設施中運行。很快就會有更多相關的設計和實現了。

Istio 中的 WebAssembly 構建

為了顯著提高性能，Istio 在 1.5 的發布中，把它的幾個擴展內置到了 Envoy中。在執行此工作時，我們把這些同樣的擴展可以作為 Proxy-Wasm 模塊進行編譯和運行，測試確保其行為沒有異常。考慮到我們認為 Wasm 支持還是 Alpha 版本，我們還沒有完全準備好將這個設置設為默認設置；然而，在我們的通用實現和主機環境還是給了我們不少信心，至少 ABI 和 SDK 已經開發完成了。

我們還是要小心地確保 Istio 控制平面及其 Envoy 配置 API 已經可以支持 Wasm。我們有一些示例來展示幾種常見的定制，例如定制頭解碼或程序中路由，這是用戶的常見要求。當將這個支持發展到 Beta 版本時，將會看到 Istio 中使用 Wasm 最佳實踐的文檔。

最后，我們正在與許多編寫了 Mixer 適配器的供應商合作，幫助他們遷移到 Wasm — 如果這是前行的最佳方式。Mixer 將在未來的版本中轉為社區項目，它將仍可用于老系統。

開發者體驗

沒有出色的開發者體驗，再強大的工具也毫無用處。Solo.io最近宣布發布 WebAssembly Hub，這是一套為 Envoy 和 Istio 做的，用于構建，部署，共享和發現 Envoy Proxy Wasm 擴展的工具和倉庫。

WebAssembly Hub 把為開發和部署 Wasm 擴展所需的許多步驟都完全自動化了。使用 WebAssembly Hub 工具，用戶可以輕松地把任何受支持語言開發的代碼編譯為 Wasm 擴展。可以將這些擴展上傳到 Hub 倉庫，并且用單個命令就將其在 Istio 中部署和刪除。

在后臺，Hub 處理了很多細節問題，例如：引入正確的工具鏈、ABI 版本驗證、權限控制等等。該工作流程還通過自動化擴展部署，消除了跨 Istio 服務代理的配置更改帶來的麻煩。此工具幫助用戶和操作員避免由于配置錯誤或版本不匹配而導致的意外行為。

WebAssembly Hub 工具提供了功能強大的 CLI 和優雅且易于使用的圖形用戶界面。WebAssembly Hub 的一個重要目標是簡化圍繞構建 Wasm 模塊的體驗，并為開發者提供共享和發現有用擴展的協作場所。

看完上述內容，你們對如何分析Envoy和Istio中的WebAssembly應用有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。