Service Mesh 發展趨勢(續)：棋到中盤路往何方 | Service Mesh Meetup 實錄

時間 2019-11-06

標籤 service mesh 發展趨勢中盤何方 meetup 實錄简体版

原文原文鏈接

敖小劍，螞蟻金服高級技術專家，十七年軟件開發經驗，微服務專家，Service Mesh 佈道師，ServiceMesher 社區聯合創始人。html

本文內容整理自 8 月 11 日 Service Mesher Meetup 廣州站主題演講，完整的分享 PPT 獲取方式見文章底部。git

前言

標題「Service Mesh發展趨勢(續)」中的「續」是指在今年5月底，我在 CloudNative Meetup上作了一個「Service Mesh發展趨勢：雲原生中流砥柱」的演講，當時主要講了三塊內容：Service Mesh 產品動態、發展趨勢、與雲原生的關係。後來有同窗反應但願部分感興趣的內容能講的更深一些，因此今天將繼續「Service Mesh 發展趨勢」這個話題。github

今天給你們分享的內容有部分是上次演講內容的深度展開，如社區關心的 Mixer v2 以及最近看到的一些業界新的技術方向，如 web assembly 技術，還有產品形態上的創新，如 google traffic director 對 Service Mesh 的虛擬機形態的創新支持。web

在 Service Mesh 出道四年之際，也但願和你們一塊兒帶着問題來對 Service Mesh 將來的發展進行一些深度思考。docker

在正式開始分享以前，讓咱們先輕鬆一下，下面是最近流行的梗，各類靈魂拷問：編程

咱們今天的分享內容，將效仿上面的方式，對 Servic Mesh 進行四個深刻靈魂的拷問。後端

Service Mesh 靈魂拷問一：要架構仍是要性能？

第一個靈魂拷問針對 Istio 的：要架構仍是要性能？瀏覽器

Istio 的回答：要架構

Istio 的回答很明確：架構優先，性能靠邊。緩存

左邊是 Istio 的架構圖，從 2017 年的 0.1 版本開始，一直到 Istio1.0，控制平面和數據平面徹底物理分離，包括咱們今天要關注的 Mixer 模塊。Sidecar 經過和 Mixer 的交互實現策略檢查和遙測報告。網絡

右邊是 Mixer 的架構圖，在 Mixer 內部提供了不少 Adapter 實現，用來提供各類功能。這些 Adapter 運行在 Mixer 進程中，所以被稱爲進程內適配器（In-Process Adapter）。

爲何 Istio 選擇 Mixer 和 Proxy 分離的架構？

咱們先來看這個架構的優勢，歸納地說優勢主要體現爲：

架構優雅
職責分明
邊界清晰

特別指出，上圖右側的紅色豎線，是 Istio0.1 到 Istio1.0 版本中 Istio 和後臺基礎設施的邊界。這意味着，從 k8s API Server 中讀取 Adapter 相關的配置信息（以 Istio CRD 的形式存在），是做爲 Istio 功能的一部分。

具體的優勢是：

Mixer 的變更不影響 Sidecar：包括 Mixer 的部署調整和版本升級；
Sidecar 無需和 Adapter 耦合，具體有：
- Sidecar 不須要讀取配置，所以也無需直接鏈接到 k8s AP Server/Istio Galley；
- Adapter 的運行時資源開銷和 Sidecar 無關；
- Sidecar 不受 Adapter 增減/更新/升級影響；
保持 Sidecar 代碼簡單：數以幾十計的 Adapter 的代碼無需直接進入 Sidecar 代碼；
數據平面可替換原則：若是有替換數據平面的需求，則 Mixer 分離的架構會讓事情簡單不少；

至於缺點，只有一個：性能很差。

而 1.1 版本以後，Istio 給出了新的回答：架構繼續優先，性能繼續靠邊。

上圖是 Istio1.1 版本以後新的架構圖，和以前的差別在於 Mixer 發生了變化，增長了進程外適配器（Out-of-Process Adapter），而 Mixer 和新的 Out-of-Process Adapter 以前依然是遠程調用。

爲何 Istio 改而選擇 Out-of-Process Adapter?

下圖是採用 Out-of-Process Adapter 以後的請求處理流程圖，Mixer 經過 Bypass Adapter 選擇須要的屬性列表，而後經過遠程調用發送給 Out-of-Process Adapter。Out-of-Process Adapter 實現和以前的 In-Process Adapter 相似的功能，可是改成獨立於 Mixer 的單獨進程。

採用 Out-of-Process Adapter 以後，Istio 的優勢更加明顯了，簡單說就是：架構更優雅，職責更分明，邊界更清晰。

並且，請注意：按照 Istio 的設想，此時 Out-of-Process Adapter 已經再也不做爲 Istio 的組成部分，它的代碼實現、安裝部署、配置、維護等職責也再也不由 Istio 承擔，請留意上圖中的紅色豎線位置。Out-of-Process Adapter 的引入，對於 Istio 來講職責和邊界的改變會讓 Istio 簡單，可是對於使用者（主要指運維）來講則增長了額外的負擔，所以形成了很大的爭議。

至於缺點，除了上述的職責轉移形成爭議外，依然只有一個：性能很差，原來 Sidecar 和 Mixer 之間的遠程調用已經讓性能變得很是糟糕，如今 Mixer 和 Out-of-Process Adapter 之間再增多加一次遠程調用，可謂雪上加霜。

Mixer v1 架構的優缺點分析

Mixer v1 架構的優勢主要體現爲：

集中式服務：提升基礎設施後端的可用性，爲前置條件檢查結果提供集羣級別的全局 2 級緩存；
靈活的適配器模型，使其如下操做變得簡單：

運維添加、使用和刪除適配器；
開發人員建立新的適配器（超過20個適配器）；

而 Mixer v1 架構的缺點，則主要體現爲：

管理開銷：

管理 Mixer 是許多客戶不想負擔的；
而進程外適配器強制運維管理適配器，讓這個負擔更加劇；

性能：

即便使用緩存，在數據路徑中同步調用 Mixer 也會增長端到端延遲；
進程外適配器進一步增長了延遲；
受權和認證功能是自然適合 mixer pipeline 的，可是因爲 mixer 設計的延遲和 SPOF（單點故障）特性，致使直接在 Envoy 中實現(Envoy SDS)；

複雜性：

Mixer 使用一組稱爲模板的核心抽象，來描述傳遞給適配器的數據。這些包括「metrics」，「logentry」，「tracepan」等。這些抽象與後端想要消費的數據不匹配，致使運維須要編寫一些手動配置，以便在規範的 Istio 樣式和後端特定的樣式之間進行映射。本來指望這種映射能夠在適配器中實現很大程度上的自動化，可是最終仍是太複雜並須要手動配置。

備註：上述優勢和缺點的描述摘錄自 mixer v2 proposal 。

其中，Mixer 性能問題一直以來都是 Istio 最被人詬病的地方。

那問題來了：若是要性能，該怎麼作？

下圖是 Mixer v1 的調用流程，Proxy/Sidecar 是請求數據的起點，Infrastructure Backend 是終點。Mixer v1 性能很差的緣由是多了 Mixer 的一次遠程訪問，而 Out-of-Process Adapter 由於又額外引入了一次遠程調用，致使性能更加糟糕：

所以，要完全解決遠程調用引入太多而形成的性能問題，答案很明顯：

將 Mixer 的功能內置到 Sidecar 中，使用 In-Process Adapter ，直接鏈接 Sidecar 和 Infrastructure Backend。

Mixer v2

Mixer 帶來的性能問題，以及 Mixer Cache 的失效，致使爲了獲得一個可用的性能，必須合併 Mixer 到 Sidecar。關於這個論斷和行動，螞蟻金服先行一步，在去年個人演講《大規模微服務架構下的 Service Mesh 探索之路》(演講時間：2018-06-30)中就介紹了螞蟻金服的 Service Mesh 方案，其中和 Istio 最大的變化就是合併 Mixer：

而在 2018 年末，Istio 社區終於提出了 Mixer v2 的 Proposal：Mixer V2 Architecture。

具體內容請見地址：

https://docs.google.com/document/d/1QKmtem5jU_2F3Lh5SqLp0IuPb80_70J7aJEYu4_gS-s/edit#heading=h.hvvcgepdykro

也能夠看我以前對這個內容的摘要翻譯：https://skyao.io/learning-istio/mixer/design/v2.html

下圖是這個 Mixer V2 Architecture 的信息摘要，當前狀態爲 In Review，建立時間爲 2018年12月18，迄今八個月：

Mixer v2 Proposal 的內容比較多，咱們忽略各類細節，只看最核心的內容：

Mixer-In-Proxy. Mixer will be rewritten in C++ and directly embedded in Envoy. There will no longer be any stand-alone Mixer service. This will improve performance and reduce operational complexity. Mixer 合併進 Proxy。 Mixer 將用 C++ 重寫並直接嵌入到 Envoy。將再也不有任何獨立的 Mixer 服務。這將提升性能並下降運維複雜性。

Mixer v2 的架構圖以下：

Service Mesh 靈魂拷問二：性能有了，架構怎麼辦？

Mixer 合併到 Sidecar 以後，性能有了，架構怎麼辦？這是咱們今天的第二個靈魂拷問。

之因此提出這個問題，在於咱們前面列出的 Mixer v1 的各類優勢，在將 Mixer 簡單合併到 Sidecar 以後，這些原來的優勢就會搖身一變成爲新方式下的缺點，而這是比較難接受的。從這個角度說，Istio 選擇 Mixer v1 的架構也不是徹底沒有理由，只是性能上付出的代價過於高昂沒法接受。

Mixer v1 的優勢不該該成爲 Mixer v2 的缺點

這是咱們對於將 Mixer 合併到 Sidecar 的要求，最起碼不要所有優勢都成爲缺點。

合併沒問題，如何合併纔是問題！

Envoy 的可擴展設計

Envoy 在設計上是可擴展的，設計有大量的擴展點：

L4/L7 filters
Access loggers
Tracers
Health checkers
Transport sockets
Retry policy
Resource monitors
Stats sink

而 Envoy 的擴展方式也有三種：

C++：直接編碼；
Lua：目前僅限於 HTTP Traffic；
Go extensions：beta, 用於 Cilium；

可是這三種擴展方式對於 Mixer 來講都並不理想，Lua 和 Go extension 不適用於 Mixer，而 C++ 直接編碼方式則就會真的讓以前的全部優勢直接變成缺點。

Envoy 最新嘗試的新擴展方式 Web Assembly，則成爲咱們今天的但願所在：

最近 Envoy 在開始提供 WASM 的支持，具體能夠看 Support WebAssembly (WASM) in Envoy 這個 issue 的描述，目前從 github 的 milestone 中看到 Envoy 計劃在1.12版本提供對 WASM 的支持（Envoy 1.11版本發佈於7月12日）。

還有一個 envoy-wasm項目，定位爲"Playground for Envoy WASM filter"。

WASM 簡單介紹

這裏對 Web Assembly 作一個簡單介紹，首先看來自 Mozilla 的官方定義：

WebAssembly 是一種新的編碼方式，能夠在現代的網絡瀏覽器中運行－它是一種低級的類彙編語言，具備緊湊的二進制格式，能夠接近原生的性能運行，併爲諸如 C / C ++ 等語言提供一個編譯目標，以便它們能夠在 Web 上運行。它也被設計爲能夠與 JavaScript 共存，容許二者一塊兒工做。

更通俗的理解是：

WebAssembly 不是一門編程語言，而是一份字節碼標準。WebAssembly 字節碼是一種抹平了不一樣 CPU 架構的機器碼，WebAssembly 字節碼不能直接在任何一種 CPU 架構上運行，但因爲很是接近機器碼，能夠很是快的被翻譯爲對應架構的機器碼，所以 WebAssembly 運行速度和機器碼接近。（類比 Java bytecode）備註：摘錄自 http://blog.enixjin.net/webassembly-introduction/

而使用 Web Assembly 擴展 Envoy 的好處是：

避免修改 Envoy；
避免網絡遠程調用（check & report）；
經過動態裝載（重載）來避免重啓 Envoy；
隔離性；
實時 A/B 測試；

Envoy 的 WASM 支持

Envoy 支持 Web Assembly 的架構和方式以下圖所示：

備註：內容來自演講「Extending Envoy with WebAssembly」

目前 Envoy 支持的 Web Assembly VM 有：

WAVM (https://github.com/WAVM/WAVM)
V8 (https://v8.dev/)
Null Sandbox (use the API, compile directly into Envoy)

Mixer v2 和 WASM

Mixer v2 的終極目標形態應該是這樣：

Mixer 合併到 Envoy：Adapter 以 In-Proxy Adapter 的形式存在；
Envoy 支持 Web Assembly 擴展：各類 Adapter 以高級語言編寫，而後編譯爲 WASM，再被 Envoy 加載（靜態/動態都可）；

咱們欣喜的看到，在 WASM 這樣的「黑科技」的加持下，Istio 終於能夠在彌補性能缺陷的同時，在系統架構上依然最大限度的維持 Mixer v1 的架構優雅、職責分明和邊界清晰。

基於 WASM 擴展的 Mixer v2 真是一個使人興奮而期待的新穎設計。

而對於 Mixer 的性能問題的解決方案，廣大 Istio 社區可謂望穿秋水，從 2017 年初 Istio 開源發佈 0.1 版本到今天，兩年多時間過去，終於 Mixer v2 開始正視 Mixer 性能問題。可是，Mixer v2 要真正落地，還有很是長的路要走。

要實現如上圖所示 Mixer v2 終極目標形態，須要：

Envoy 提供對 WASM 的支持；
Istio 大規模架構調整，實施 mixer v2；

目前，Envoy 對 Web Assembly 的支持預計有但願在 3-6 個月內實現，具體狀況能夠經過下面的 Issue 來了解：

https://github.com/envoyproxy/envoy/issues/4272

咱們從這個 Issue 中能夠大致總結 Envoy 對 WASM 支持的過程：

2018年8月28日，Issue 建立，提交對 WASM 支持的想法；
2018年10月開始動手，進行 poc；
2019年5月 poc 完成，而後建立 envoy-wasm 項目；
目前這個 Issue 放在 Envoy 的下一個 milestone1.12 中；

Envoy 最近剛發佈了 1.11 版本，根據最近兩年中 Envoy 的穩健表現，Envoy 通常三個月發佈一個版本，這樣預計 1.12 版本會在將來三個月內提供。即便 1.12 版本未能完成，延後到 1.13 版本，也會在六個月內提供。

可是 Istio 方面的進展，則很是不樂觀：Mixer v2 從提出到如今 8 個月了，依然是 In Review 狀態。

考慮到過去兩年間 Istio 團隊表現出來的組織能力和執行能力，我我的持悲觀態度，個人疑問和擔心是：

Istio 可否接受 Mixer v2？
若是接受，何時開工？
若是開工，何時完工？
若是完工，何時穩定？

Mixer v2 雖然前景美好，奈何還需時日，尤爲取決於 Istio 的表現：社區的殷切期待和 Istio 的猶豫未決可謂回味無窮。

最後感嘆一聲：南望王師又一年，王師還在 Review 間......

Service Mesh 靈魂拷問三：要不要支持虛擬機？

在聊完性能與架構以後，咱們繼續今天的第三個靈魂拷問：在有了高大上的容器/k8s/雲原生，還要不要支持土裏土氣的虛擬機？

Service Mesh 主流產品對虛擬機的支持

首先咱們看一下 Service Mesh 主流產品對虛擬機的支持狀況：

Service Mesh 的第一代產品，典型如 Linkered 1.* 和 Envoy，自然支持虛擬機
Service Mesh 的第二代產品，如 Istio，在剛開始發佈時還計劃提供對非 k8s 的支持，可是後面實質性的取消，基本只有在 k8s 上纔好用。Linkerd 2.* 更是明確只提供 k8s 的支持。
AWS 在 2018 年推出的 app mesh，不只僅能夠支持虛擬機，並且能夠支持虛擬機和容器相互訪問，稍後Google 推出了 Traffic Director 產品，也是一樣思路。

稍加回顧，就會發現：歷史老是驚人的類似，螺旋式上升？波浪式起伏？

Service Mesh 對於虛擬機的態度，從 Linkerd 1.* 和 Envoy的支持，到 Istio / Linkerd 2.* 的不支持，再到 AWS app mesh 和 Google Traffic Director 的支持，可謂一波三折。將來若是有新形態的 Service Mesh 產品出現，對虛擬機的支持又會是如何？支持仍是不支持，咱們拭目以待。

虛擬機支持與否的背後

第一個轉折容易理解：相比虛擬機，k8s 提供了太多便利。隨着容器的普及，k8s 的一統天下，社區對雲原生的日益接受，虛擬機模式失寵容易理解。

輕鬆一下，引用最近的一個梗「小甜甜 VS 牛夫人」，感受能夠很是形象的描述虛擬機失寵的場面：

第二個轉折該如何解釋？

AWS App Mesh 提供對虛擬機支持是容易理解的，畢竟 AWS 上目前仍是以虛擬機爲主，並且 k8s/雲原生原本就是 Google 和 AWS 競爭的重要武器，AWS app mesh 提供對虛擬機的支持，而且能夠打通就有的虛擬機體現和新的k8s 體系，對AWS意義重大。

可是，做爲 k8s 和雲原生的主要推進力量， Google 爲何在 Traffic Director 這個產品上沒有繼續 Istio / Linkerd2 只支持 k8s 的作法，而是效仿 AWS 呢？

緣由簡單而直白：理想和現實的差距。

理想：雲原生普及，容器廣泛落地，生產上 k8s 普遍使用；
現實：虛擬機大量存在，大量公司未能有效掌握 k8s，大部分應用仍是運行在虛擬機上；

關於 Service Mesh 形態和雲原生未能普及的思考，去年（2018-02-10 ）在 DreamMesh拋磚引玉(2)-CloudNative 這篇博客中我有詳細描述，當時也和不少社區同窗深刻討論。援引當時的一小段總結：

理想很豐滿，現實很骨感。Cloud Native 雖然使人嚮往，然而現實中，有多少企業是真的作好了 Cloud Native 的準備？問題：到底該先容器/k8s，再上微服務/Service Mesh；仍是先微服務/Service Mesh，再上容器/k8s？每一個公司都會有本身的實際狀況和選擇。

在去年末（2018-11-25），我和同事曾經作過一個名爲 "螞蟻金服 Service Mesh 漸進式遷移方案" 的主題演講，詳細描述了 Service Mesh 和 k8s 落地可能的多種演進路線：

在關於先 Service Mesh，仍是先 k8s 的這個問題上，Google Traffic Director 的選擇是：支持 Service Mesh 先行。即允許應用在進行容器化改造和 k8s 落地以前，也可以從 Service Mesh 獲益。爲此，Google Traffic Director 在標準的 k8s 以外，爲基於虛擬機的應用（未作容器化改造）和基於自管理的 docker 容器（有容器但不是 k8s）提供支持：

對此，Traffic Director 官方文檔是這樣描述的：「按您的節奏進行現代化改造」。

創新：Google Traffic Director 的虛擬機支持

對於如何在虛擬機上提供 Service Mesh 的支持，Google Traffic Director 給出了一個創新的思路。

爲了方便管理虛擬機實例，Google Traffic Director 提供了託管式實例組（Managed Instance Group，實際來自 GCP），效仿容器和 k8s 的方式來管理虛擬機：

其中最重要的是提供實例模版（Instance Template）來進行虛擬機的硬件配置/操做系統配置，而後基於實例模版來建立虛擬機實例，並經過自動啓動腳原本獲取並啓動應用，從而實現了從零啓動一個運行於虛擬機的應用的全過程自動化。

而實例模版+自動啓動腳本配合，能夠實現相似容器和k8s下的不少相似功能，好比應用版本升級時只須要修改實例模版（和其中的自動啓動腳本），相似容器下的修改鏡像文件。實例模版提供對實例副本數的管理，包括固定大小和自動伸縮（由此提供類serverless的特性）。

相似的，爲了方便管理運行於虛擬機上的應用實例，Traffic Director 效仿 k8s/Istio 的方式來管理服務：

Traffic Director 提供了可同時用於k8s/容器/虛擬機三種模式下的統一的服務抽象，允許在控制檯手工建立服務並關聯到實例模版（以及實例模版背後的虛擬機實例和運行其上的應用），能夠經過託管實例組配置健康檢查/灰度發佈等高級特性。

Google Traffic Director 在 Service Mesh 虛擬機支持上的創新思路在於：補齊虛擬機的短板，向容器看齊，維持一致的用戶體驗。以下圖所示，在經過託管式實例組向容器/k8s 看齊（固然很是有限）以後，配合統一的 Traffic Director 服務抽象，就能夠實現統一管理應用，如配置路由規則。從而實如今最上層爲不一樣 Service Mesh 模式提供一致的用戶體驗：

經過上述的創新方式，Traffic Director 將 Service Mesh 對虛擬機的支持提高到新的高度。

備註：關於Google Traffic Director 對虛擬機支持的細節，請見個人另外一篇博客文檔 "Service Mesh先行：Google Traffic Director實踐分析"

Service Mesh 靈魂拷問四：說好的供應商不鎖定呢？

在誇讚完 Google 和 Traffic Director 以後，咱們進行今天的最後一個靈魂拷問，這個問題的目標直指 Google：

說好的供應商不鎖定呢？

供應商不鎖定，是 Google 和 CNCF 一直強調和倡導的理念，也是雲原生最重要的基石之一。Google 一直用供應商不鎖定這塊大石頭狠狠的砸 AWS 的腦殼，可是，這塊石頭也是能夠用來砸 Google 本身的腳的。

SMI 的意義和最近的社區支持狀況

在 Service Mesh 領域，供應商不鎖定的典型表明，就是 SMI（Service Mesh Interface）。

備註：關於 Service Mesh Interface 的介紹，我以前的博客文檔 Service Mesh Interface詳細介紹有很是詳細的描述。

讓咱們來共同回味 SMI 爲整個 Service Mesh 社區帶來的美好願景：

「SMI 是在 Kubernetes 上運行服務網格的規範。它定義了由各類供應商實現的通用標準。這使得最終用戶的標準化和服務網格供應商的創新能夠一箭雙鵰。SMI 實現了靈活性和互操做性。」

「SMI API 的目標是提供一組通用的，可移植的 Service Mesh API，Kubernetes 用戶能夠以供應商無關的方式使用這些 API。經過這種方式，能夠定義使用 Service Mesh 技術的應用程序，而無需緊密綁定到任何特定實現。」

下圖這張圖可讓咱們更好的理解 SMI 在 Service Mesh 生態中的位置和 SMI 對整個生態的重要：

在 SMI 發佈以後，最近 Service Mesh 社區的主要玩家都紛紛開始提供對 SMI 的支持：

Linkerd：發佈於 2019-07-11的 Linkerd 2.4.0 版本開始支持 SMI；
Consul Connect: 發佈於 2019-07-09 的 Consul 1.6 版本開始支持 SMI；

Google 在 Service Mesh 標準化上的反常表現

標準化是供應商不鎖定的基石，只有實現標準化，才能基於統一的標準打造社區和生態，上層的應用/工具等纔有機會在不一樣的廠商實現之間遷移，從而打造一個有序競爭的積極向上的生態系統。

Service Mesh 問世四年來，在標準化方面作的並不到位，而 Google 在 Service Mesh 標準化上的表現更是反常。具體說，SMI 出來以前：

Istio 遲遲未貢獻給 CNCF，能夠說 Istio 至今依然是 Google（還有 IBM/Lyft）的項目，而不是社區的項目；
Istio API 是私有 API，未見有標準化動做；
Envoy xDS v2 API 是社區事實標準，但這實際上是 Envoy 的功勞；
統一數據平面 API（UDPA），感受更像是 Envoy 在推進，和 Istio 關係不大；

Google 做爲 Service Mesh 界的領頭羊，在標準化方面表現可謂消極怠工，幾乎能夠說是無所做爲。以致於 SMI 這樣的標準，竟然是微軟出面牽頭。而在 SMI 出來以後，除 Istio/AWS 以外幾乎全部 Service Mesh 玩家都參與的狀況下，依然未見 Istio 有積極迴應。

AWS 不加入社區容易理解，畢竟 AWS 自成體系，AWS 原本也就是「供應商不鎖定」的革命對象。而 Google 這位「供應商不鎖定」運動的發起者，在 Service Mesh 標準化上的反常表現，倒是回味無窮：屠龍的勇士，終將變成惡龍嗎？

再次以此圖，致敬 AWS和 Google：

下圖是目前的 SMI 陣營：聚集幾乎全部 Service Mesh 玩家，惟獨 AWS 和 Google 缺席：

期待 Google 後續的行動，說好的供應商不鎖定，請勿忘此初心。