前言
本文內容整理自8月10日在 ServiceMesh Meetup 廣州站發表的主題演講。標題“Service Mesh發展趨勢(續)”中的“續”是指在今年5月底，我在 CloudNative Meetup上做了一個“ServiceMesh發展趨勢：雲原生中流砥柱”的演講，當時主要講了三塊內容：Service Mesh產品動態，發展趨勢，與雲原生的關係。後來有同學反應希望部分感興趣的內容能講的更深一些，所以今天將繼續“ServiceMesh發展趨勢”這個話題。
今天給大家分享的內容有部分是上次演講內容的深度展開，如社區關心的Mixer v2；以及最近看到的一些業界新的技術方向，如web assembly技術，還有產品形態上的創新，如google traffic director對servicemesh的虛擬機形態的創新支持。
在ServiceMesh出道四年之際，也希望和大家一起帶着問題來對ServiceMesh未來的發展進行一些深度思考。
在正式開始分享之前，讓我們先輕鬆一下，下面是最近流行的梗，各種靈魂拷問：
而我們今天的分享內容，將效仿上面的方式，對 ServicMesh 進行四個深入靈魂的拷問。
ServiceMesh靈魂拷問一：要架構還是要性能？
第一個靈魂拷問針對 Istio 的：要架構還是要性能？
Istio的回答：要架構
Istio的回答很明確：架構優先，性能靠邊。
左邊是 Istio 的架構圖，從2017年的 0.1 版本開始，一直到 Istio1.0，控制平面和數據平面完全物理分離，包括我們今天要關注的Mixer模塊。Sidecar 通過和 Mixer 的交互實現策略檢查和遙測報告。
右邊是 Mixer 的架構圖，在 Mixer 內部提供了很多 Adapter 實現，用來提供各種功能。這些 Adapter 運行在 Mixer 進程中，因此被稱爲進程內適配器（In-Process Adapter）。
爲什麼Istio選擇Mixer和Proxy分離的架構？
我們先來看這個架構的優點，概括地說優點主要體現爲：
- 架構優雅
- 職責分明
- 邊界清晰
特別指出，上圖右側的紅色豎線，是Istio 0.1 到 Istio 1.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)中就介紹了螞蟻的ServiceMesh方案，其中和Istio最大的變化就是合併Mixer：
而在 2018年底，Istio社區終於提出了 Mixer v2 的 Proposal：Mixer V2 Architecture。
具體內容請見地址：
也可以看我之前對這個內容的摘要翻譯：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 的架構圖如下：
ServiceMesh靈魂拷問二：性能有了，架構怎麼辦？
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間……
ServiceMesh靈魂拷問三：要不要支持虛擬機？
在聊完性能與架構之後，我們繼續今天的第三個靈魂拷問：在有了高大上的容器/k8s/雲原生，還要不要支持土裏土氣的虛擬機？
ServiceMesh 主流產品對虛擬機的支持
首先我們看一下 ServiceMesh 主流產品對虛擬機的支持情況：
- ServiceMesh 的第一代產品，典型如
Linkered 1.*和 Envoy，天然支持虛擬機 - ServiceMesh 的第二代產品，如 Istio，在剛開始發佈時還計劃提供對非k8s的支持，但是後面實質性的取消，基本只有在k8s上纔好用。
Linkerd 2.*更是明確只提供k8s的支持。 - AWS 在2018年推出的 app mesh，不僅僅可以支持虛擬機，而且可以支持虛擬機和容器相互訪問；稍後Google 推出了 Traffic Director 產品，也是同樣思路。
稍加回顧，就會發現：歷史總是驚人的相似，螺旋式上升？波浪式起伏？
ServiceMesh 對於虛擬機的態度，從 Linkerd 1.* 和 Envoy的支持，到 Istio / Linkerd 2.* 的不支持，再到 AWS app mesh 和 Google Traffic Director 的支持，可謂一波三折。未來如果有新形態的 ServiceMesh 產品出現，對虛擬機的支持又會是如何？支持還是不支持，我們拭目以待。
虛擬機支持與否的背後
第一個轉折容易理解：相比虛擬機，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，大部分應用還是運行在虛擬機上
關於ServiceMesh形態和雲原生未能普及的思考，去年（2018-02-10
）在 DreamMesh拋磚引玉(2)-CloudNative 這篇博客中我有詳細描述，當時也和很多社區同學深入討論。援引當時的一小段總結：
理想很豐滿，現實很骨感。Cloud Native雖然令人嚮往，然而現實中，有多少企業是真的做好了Cloud Native的準備？
問題：到底該先容器/k8s，再上微服務/servicemesh；還是先微服務/servicemesh，再上容器/k8s？
每個公司都會有自己的實際情況和選擇。
在去年底（2018-11-25），我和同事曾經做過一個名爲 “螞蟻金服Service Mesh漸進式遷移方案” 的主題演講，詳細描述了 Service Mesh 和 k8s 落地可能的多種演進路線：
在關於先ServiceMesh，還是先k8s的這個問題上，Google Traffic Director的選擇是：支持ServiceMesh先行。即容許應用在進行容器化改造和k8s落地之前，也能夠從ServiceMesh獲益。爲此，Google Traffic Director在標準的k8s之外，爲基於虛擬機的應用（未做容器化改造）和基於自管理的docker容器（有容器但不是k8s）提供支持：
對此，Traffic Director 官方文檔是這樣描述的：“按您的節奏進行現代化改造”。
創新：Google Traffic Director的虛擬機支持
對於如何在虛擬機上提供ServiceMesh的支持，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 在 ServiceMesh 虛擬機支持上的創新思路在於：補齊虛擬機的短板，向容器看齊，維持一致的用戶體驗。如下圖所示，在通過託管式實例組向容器/k8s看齊（當然非常有限）之後，配合統一的 Traffic Director 服務抽象，就可以實現統一管理應用，如配置路由規則。從而實現在最上層爲不同ServiceMesh模式提供一致的用戶體驗：
通過上述的創新方式，Traffic Director 將 ServiceMesh 對虛擬機的支持提升到新的高度。
備註：關於Google Traffic Director 對虛擬機支持的細節，請見我的另一篇博客文檔 “ServiceMesh先行：Google Traffic Director實踐分析”
ServiceMesh靈魂拷問四：說好的供應商不鎖定呢？
在誇讚完 google 和 Traffic Director 之後，我們進行今天的最後一個靈魂拷問，這個問題的目標直指 google：
說好的供應商不鎖定呢？
供應商不鎖定，是 google 和 CNCF 一直強調和倡導的理念，也是雲原生最重要的基石之一。Google 一直用供應商不鎖定這塊大石頭狠狠的砸AWS的腦袋，但是，這塊石頭也是可以用來砸google自己的腳的。
SMI的意義和最近的社區支持情況
在 ServiceMesh 領域，供應商不鎖定的典型代表，就是SMI（Service Mesh Interface）。
備註：關於 Service Mesh Interface 的介紹，我之前的博客文檔 Service Mesh Interface詳細介紹 有非常詳細的描述。
讓我們來共同回味 SMI 爲整個 ServiceMesh 社區帶來的美好願景：
“SMI 是在 Kubernetes 上運行服務網格的規範。它定義了由各種供應商實現的通用標準。這使得最終用戶的標準化和服務網格供應商的創新可以兩全其美。SMI 實現了靈活性和互操作性。”
“SMI API的目標是提供一組通用的，可移植的Service Mesh API，Kubernetes用戶可以以供應商無關的方式使用這些API。通過這種方式，可以定義使用Service Mesh技術的應用程序，而無需緊密綁定到任何特定實現。”
下圖這張圖可以讓我們更好的理解 SMI 在 ServiceMesh 生態中的位置和 SMI 對整個生態的重要：
在 SMI 發佈之後，最近 ServiceMesh 社區的主要玩家都紛紛開始提供對 SMI 的支持：
- Linkerd：發佈於 2019-07-11的 Linkerd 2.4.0 版本開始支持 SMI
- Consul Connect: 發佈於 2019-07-09 的 Consul 1.6 版本開始支持 SMI
Google在ServiceMesh標準化上的反常表現
標準化是供應商不鎖定的基石，只有實現標準化，才能基於統一的標準打造社區和生態，上層的應用/工具等纔有機會在不同的廠商實現之間遷移，從而打造一個有序競爭的積極向上的生態系統。
ServiceMesh 問世四年來，在標準化方面做的並不到位，而Google在ServiceMesh標準化上的表現更是反常。具體說，SMI出來之前：
- Istio遲遲未貢獻給CNCF，可以說Istio至今依然是Google（還有IBM/Lyft）的項目，而不是社區的項目。
- Istio API 是私有API，未見有標準化動作
- Envoy xDS v2 API是社區事實標準，但這其實是Envoy的功勞
- 統一數據平面API（UDPA），感覺更像是Envoy在推動，和Istio關係不大
Google作爲ServiceMesh界的領頭羊，在標準化方面表現可謂消極怠工，幾乎可以說是無所作爲。以至於SMI這樣的標準，居然是微軟出面牽頭。而在SMI出來之後，除Istio/AWS之外幾乎所有ServiceMesh玩家都參與的情況下，依然未見Istio有積極迴應。
AWS不加入社區容易理解，畢竟AWS自成體系，AWS本來也就是“供應商不鎖定”的革命對象。而Google這位“供應商不鎖定”運動的發起者，在 ServiceMesh 標準化上的反常表現，卻是耐人尋味：屠龍的勇士，終將變成惡龍嗎？
再次以此圖，致敬AWS和google：
下圖是目前的SMI陣營：彙集幾乎所有ServiceMesh玩家，唯獨AWS和Google缺席：
期待Google後續的行動，說好的供應商不鎖定，請勿忘此初心。
總結與展望
ServiceMesh 出道四年，對於一個新技術，四年時間不算短，到了該好好反思當下和着眼未來的時候了，尤其是目前 ServiceMesh 在落地方面表現遠不能令人滿意的情況下。
正如標題所言：棋到中盤，路往何方？
今天的Servicemesh發展趨勢探討，我們以靈魂拷問的方式提出了四個問題。每一個問題和答案，都會深刻影響未來幾年Servicemesh的走向，請大家在未來一兩年間密切關注這些問題背後所代表的ServiceMesh技術發展走向和產品形態演進：
- 要架構，還是要性能？：關注點在於ServiceMesh的落地，落地還有落地。性能不是萬能的，但是沒有性能是萬萬不能的
- 性能有了，架構怎麼辦？：關注點在於迴歸性能之後的架構優化，以創新的方式實現性能與架構的兼得，用新技術來解決老問題
- 要不要支持虛擬機？：關注點依然是落地，對現實的妥協或者說學會接地氣，以創新思維來實現用新方法解決老問題
- 說好的供應商不鎖定呢？：關注點在於標準化，還有標準化之後的生態共建和生態繁榮。
本文轉載自敖小劍的博客。
原文鏈接：
https://skyao.io/talk/201908-servicemesh-development-trend2/