Service Mesh 是新瓶裝舊酒嗎？

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

導讀：在即將過去的 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等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的技術公眾號，”

標籤：其他

上一篇：C#實作的一些常見時間格式

下一篇：吳恩達EX4