Service Mesh 是新瓶裝舊酒嗎？

點擊下載《不同的 雙11 技術：阿里巴巴經濟體雲原生實踐》

本文節選自《不同的 雙11 技術：阿里巴巴經濟體雲原生實踐》一書，點擊上方圖片便可下載！

做者 | 李雲（花名：至簡） 阿里雲高級技術專家

導讀：在即將過去的 2019 年，Service Mesh 開源產品的成熟度雖在全球範圍內沒有發生質的變化，但在國內仍出現了一些值得特別關注的事件。好比：阿里巴巴在 雙11 的部分電商核心應用上落地了完整的 Service Mesh 解決方案，藉助 雙11 的嚴苛業務場景完成了規模化落地前的初步技術驗證。本文做者將結合本身在阿里巴巴落地實踐 Service Mesh 過程當中的觀察與思考，來和你們進行分享。

Service Mesh 是新瓶裝舊酒嗎？

新技術出現時所主張的價值必定會引起相應的探討，Service Mesh 也不例外。

以往，懷疑 Service Mesh 價值的觀點主要有兩大類。

• 第一類是應用的數量並無達到必定的規模，在 Service Mesh 增長運維和部署複雜度的情形下，認爲所帶來的成本和複雜度高於所得到的收益。

從根本上來看，這一類並不是真正懷疑 Service Mesh 的價值，而是主張在 Service Mesh 尚未徹底成熟和普及的情形下，在將來合適的時機再考慮採納。固然，我在與外部客戶交流時也碰到一些特例，他們即使在應用數不多的情形下，仍但願經過 Service
Mesh 去解決非 Java 編程語言（比方說 Go）的分佈式鏈路追蹤等服務治理問題，雖然說這些能力在 Java 領域有相對成熟的解決方案，但在非 Java 領域確實偏少，因此很天然地想到了採用 Service Mesh。

• 第二類懷疑 Service Mesh 價值的，是應用的數量具備至關的規模且對分佈式應用的規模問題也有很好的認知，但因爲在發展的過程當中已經積累了與 Service Mesh 能力至關的那些（非體系化的）技術，形成初識 Service Mesh 時有「老酒換新瓶」的感受而不承認其價值。阿里巴巴過去也曾屬於這一陣營。

阿里巴巴在分佈式應用的開發和治理方面的總體解決方案的探索有超過十年的歷程，且探索過程持續地經過 雙11 這樣的嚴苛場景作檢驗和孵化，採用單一的 Java 語言打造了一整套的技術。即使如此，應對分佈式應用的規模問題依然不輕鬆，體現於由於缺少頂層設計而面臨體系性不足，加之對技術產品自身的用戶體驗缺少重視，最終致使運維成本和技術門檻都偏高。在面臨這些陣痛之際，雲原生的概念逐漸清晰地浮出了水面。

雲原生主張技術產品在最爲嚴苛的場景下仍能提供必定質量的服務而體現良好彈性，同時也強調技術產品自己應當具備良好的易用性，以及未來爲企業須要多雲和混合雲的 IT 基礎設施提供支撐（即：幫助實現分佈式應用的可移植性）。

雲原生的概念不只很好地契合了阿里巴巴集團在技術發展上亟待解決的陣痛，也迎合了阿里巴巴將雲計算做爲集團戰略、讓雲計算普惠社會的初衷。在這一背景下，阿里巴巴作出了全面雲原生化的決定，Service Mesh 做爲雲原生概念中的關鍵技術之一，固然也包含在其中。

Service Mesh 給阿里巴巴帶來的價值

Service Mesh 所帶來的第一個變化體現於：服務治理手段從過去的框架思惟向平臺思惟轉變。

這種轉變並不是後者否認前者，而是先後者相結合去更好地發揮各自的優點。兩種思惟的最大區別在於，平臺思惟不只能實現應用與技術基礎設施更好的解耦，也能經過平臺的彙集效應讓體系化的頂層設計有生髮之地。

框架思惟向平臺思惟轉變在執行上集中體現於「輕量化」和「下沉」兩個動做。

• 輕量化是指將那些易變的功能從框架的 SDK 中移出，結果是使用了 SDK 的應用變得更輕，免除了因易變功能持續升級所帶來的低效；也完全讓應用的開發者無需關心這些功能，讓他們能更好地聚焦於業務邏輯自己；

• 從框架中移出的功能放到了 Service Mesh 的 Sidecar 中實現了功能下沉。

Service Mesh 做爲平臺性技術，將由雲廠商去運維和提供相應的產品，經過開源所構建的全球事實標準一旦被全部雲廠商採納並實現產品化輸出，那時應用的可移植性問題就能水到渠成地解決。

功能下沉在阿里巴巴落地 Service Mesh 的過程當中也看到了相應的價值。阿里巴巴的電商核心應用基本上都是用 Java 構建的，在 Mesh 化以前，RPC 的服務發現與路由是在 SDK 中完成的，爲了保證 雙11 這樣的流量洪峯場景下的消費者用戶體驗，會經過預案對服務地址的變動推送作降級，避免由於頻繁推送而形成應用進程出現 Full GC。Mesh 化以後，SDK 的那些功能被放到了 Sidecar（開發語言是 C++）這一獨立進程中，這使得 Java 應用進程徹底不會出現相似場景下的 Full GC 問題。

軟件設計的質量主要體如今「概念」和「關係」兩個詞上。

一樣功能的一個系統，不一樣的概念塑造與切分將產生徹底不一樣的設計成果，甚至影響到最終軟件產品的工程質量與效率。當概念肯定後，關係也隨之確立，而關係的質量水平體如今解耦的程度上。Service Mesh 使得應用與技術基礎設施之間的關係變得更鬆且穩定，經過流量無損的熱升級方案，使得應用與技術基礎設施的演進變得獨立，從而加速各自的演進效率。軟件不成熟、不完善並不可怕，可怕的是演進起來太慢、包袱過重。

阿里巴巴在落地 Service Mesh 的過程當中，體會到了鬆耦合所帶來的巨大工程價值。當應用被 Mesh 化後，接下來的技術基礎設施的升級對之就透明瞭，以前由於升級工做所需的人力配合問題能夠經過技術產品化的手段徹底釋放。另外，以往應用進程中包含了業務邏輯和基礎技術的功能，不容易講清楚各自對計算資源的消耗，Service Mesh 經過獨立進程的方式讓這一問題得以更好地隔離而實現量化，有了量化結果才能更好地對技術作優化。

Service Mesh 所帶來的第二個變化在於：技術平臺的建設從面向單一編程語言向面向多編程語言轉變。

對於初創或小規模企業來講，業務應用的開發採用單一的編程語言具備明顯優點，體現於由於個體掌握的技術棧相同而能帶來良好的協做效率，但當企業的發展進入了多元化、跨領域、規模更大的更高階段時，多編程語言的訴求就隨之產生，對於阿里巴巴這樣的雲廠商來講更是如此（所提供的雲產品不可能過分約束客戶所使用的編程語言）。多編程語言訴求的背後是每種編程語言都有本身的優點和適用範圍，須要發揮各自的優點去加速探索與創新。
 
從技術層面，這一轉變意味着：

• 第一，技術平臺的能力須要儘量地服務化，避免由於服務化不完全而須要引入 SDK，進而帶來多編程語言問題（即由於沒有相應編程語言的 SDK 而沒法使用該編程語言）；
• 第二，在沒法規避 SDK 的情形下，讓 SDK 變得足夠的輕且功能穩定，下降平臺化和多編程語言化的工程成本，支持多編程語言 SDK 最好的手段是採用 IDL。

從組織層面，這一轉變意味着平臺技術團隊的人員技能須要多編程語言化。一個只有單一編程語言的團隊是很難作好面向多編程語言的技術平臺的，不僅是由於視角單一，還由於沒法「吃本身的狗食」而對多編程語言問題有切膚之痛。

Service Mesh 帶來的發展機遇

在這兩個變化之下，咱們來聊一聊 Service Mesh 所帶來的發展機遇。

• 首先，Service Mesh 創造了一次以開發者爲中心去打造面向將來的分佈式應用開發平臺的機會。

在 Service Mesh 出現以前，各類分佈式服務治理技術產品的發展，缺少強有力的抓手去橫向拉通作體系化設計和完成能力複用，於是不免出現概念抽象不一致和從新造輪子的局面，最終每一個技術產品有本身的一套概念和獨立的運維控制檯。當多個運維控制檯交到開發者手上時，他們須要作大量的學習，去理解每一個運維控制檯的概念以及它們之間的關係，背後所帶來的困難和低效是很容易被人忽視的。

本質上，Service Mesh 的出現是解決微服務軟件架構之下那些藏在應用與應用之間的複雜度的。它的出現使得全部的分佈式應用的治理問題被放到了一塊兒去考慮。換句話說，由於 Service Mesh 的出現，咱們有機會就分佈式應用的治理作一次全局的設計，也有機會將各類技術產品整合到一塊兒而避免重複建設的問題。

將來的分佈式應用開發平臺必定是基於 Service Mesh 這一基礎技術的。爲此，須要借這個契機從易用性的角度從新梳理應給開發者塑造的心智。易用性心智的確立，將使得開發者能在一個運維控制檯上作最少的操做，經過爲他們屏蔽背後的技術實現細節，而減輕他們在使用時的腦力負擔，以及下降操做失誤帶來安全生產事故的可能性。

理論上，沒有 Service Mesh 以前這些工做也能作，但由於沒有具體的橫向技術作抓手而沒法落地。

• 其次，Service Mesh 給其餘技術產品創造了從新思考雲原生時代的發展機會。

有了 Service Mesh 後，之前不少獨立的技術產品（好比，服務註冊中心、消息系統、配置中心）將變成 BaaS（Backend as a Service）服務，由 Service Mesh 的 Sidecar 負責與它們對接，應用對這些服務的訪問經過 Sidecar 去完成，甚至有些 BaaS 服務被 Sidecar 終結而徹底對應用無感。

這些變化並不是弱化了那些 BaaS 服務的重要性。相反，由於其重要性而須要與 Service Mesh 作更好的整合去爲應用提供服務，與此同時探索作必定的能力加強。比方說，Service Mesh 所支持的應用版本發佈的灰度功能（包括藍綠髮布、金絲雀發佈、A/B 測試），並不是每個 BaaS 服務在 Mesh 化後就能很好地支持這一功能，而是須要作相應的技術改造才行。請注意，這裏主要講的是應用的灰度能力，而非 BaaS 服務自身的灰度能力。固然，並不妨礙探索經過 Service Mesh 讓 BaaS 服務自身的灰度工做變得簡單且低風險。

將來不少技術產品的競爭優點將體現於它可否與 Service Mesh 造成無縫整合。

無縫整合的核心驅動力，源於用戶對技術產品的易用性和應用可移植性的須要。基於這一認識，阿里巴巴正在將 RocketMQ/MetaQ 消息系統的客戶端中的重邏輯剝離到 Envoy 這一 Sidecar 中（思路依然是「下沉」），同時基於 Service Mesh 所提供的能力作必定的技術改造，以便 RocketMQ/MetaQ 能很好地支撐應用的灰度發佈。相似這樣的思考與行動，相信將來會在更多的技術產品上出現。

• 再次，Service Mesh 給技術基礎設施如何與業務基礎技術更好地協同提供了一次探索機會。

每一種業務（好比電商）都會構建基於所在領域的基礎技術，這類技術咱們稱之爲業務基礎技術。當阿里巴巴但願將某一業務的基礎技術搬到外部去服務客戶時，面臨業務基礎技術如何經過服務化去知足客戶已選擇的、與業務基礎技術不一樣的編程語言的問題，不然會出現基於 Java 構建的業務基礎技術很難與 Go 所編寫的應用協同。

在 Service Mesh 致力於解決服務化問題的過程當中，可否經過必定的技術手段，讓業務基礎技術的能力經過插件的形式「長」在 Service Mesh 之上是一個很值得探索的點。當業務基礎技術以插件的形式存在時，業務基礎技術無需以獨立的進程存在而取得更好的性能，且這一機制也能被不一樣的業務複用。阿里巴巴的 Service
Mesh 技術方案所採用的 Sidecar 開源軟件 Envoy 正在積極地探索經過 Wasm 技術去實現流量處理的插件機制，將該機制進一步演變成爲業務基礎技術插件機制是值得探索的內容。

下圖示例說明了業務基礎技術的插件機制。

圖中兩個彩色分別表明了不一樣的業務（好比一個表明電商，另外一個表明物流），兩個業務的基礎技術並不是開發了兩個獨立的應用（進程）而後作發佈和運維管理，而是基於 Wasm 所支持的編程語言實現了業務技術插件，這一點能夠理解爲用多編程語言的方式解決業務服務化問題，而非強制要求採用與 Sidecar 同樣的編程語言。插件經過 Service Mesh 的運維平臺進行管理，包含安裝、灰度、升級、監控等能力。

因爲插件是「長」在 Service Mesh 之上的，插件化的過程就是業務技術服務化的過程。

另外，Service Mesh 須要提供一種選擇能力，讓業務的應用開發者或運維者選擇本身的機器上須要哪些插件（能夠理解爲插件市場）。另外一個值得關注的點是：插件的運維和管理能力以及必定的質量保證手段由 Service Mesh 平臺提供，但運維、管理和質量保證的責任由各插件的提供者承擔。這種劃分將有效地杜絕全部插件的質量由 Service Mesh 平臺去承擔而帶來的低效，分而治之還是改善不少工程效率的良方。

• 最後，Service Mesh 給探索麪向將來的異地多活、應用永遠在線的總體技術解決方案打開了一扇大門。

服務之間的互聯互通，服務流量的控制、觀測和安全加固是微服務軟件架構下所要解決的關鍵問題，這些問題與規模化下的服務可用性和安全性緊密相關。將來，經過 Service Mesh 的流量控制能力能作不少改善應用發佈和運維效率的文章，那時才能真正看到一個靈動、稱手的雲平臺。

Service Mesh 的「三位一體」發展思路

阿里巴巴做爲雲計算技術的供應商，在探索 Service Mesh 技術的道路上，不僅是考慮如何讓雲原生技術紅利在阿里巴巴內部兌現，同時還思考着如何將技術紅利帶給更多的阿里雲客戶。基於此，阿里巴巴就 Service Mesh 的總體發展思路遵循「三位一體」，即阿里巴巴內部、阿里雲上的相應商業產品和開源軟件將採用同一套代碼。

就咱們與阿里雲客戶交流的經驗來看，他們樂於盡最大可能採用非雲廠商所特有的技術方案，以避免被技術鎖定而在將來的發展上出現掣肘。另外，他們只有採納開源的事實標準軟件纔有可能達成企業的多雲和混合雲戰略。基於客戶的這一訴求，咱們在 Service Mesh 的技術發展上特別重視參與開源事實標準的共建。在 Istio 和 Envoy 兩個開源項目上，咱們都會致力於將內部所作的那些優化反哺給開源社區。

將來，咱們將在 Service Mesh 領域堅決而紮實地探索，也必定會將探索成果和思考持續地分享給你們。

本書亮點

• 雙11 超大規模 K8s 集羣實踐中，遇到的問題及解決方法詳述
• 雲原生化最佳組合：Kubernetes+容器+神龍，實現核心系統 100% 上雲的技術細節
• 雙 11 Service Mesh 超大規模落地解決方案

「阿里巴巴雲原生微信公衆號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術公衆號。」