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

> **導讀**：在即將過去的 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 所帶來的第二個變化在於：技術平臺的建設從面向單一程式語言向面向多程式語言轉變。

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

- 第一，技術平臺的能力需要儘可能地服務化，避免因為服務化不徹底而需要引入 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 的運維平臺進行管理，包含安裝、灰度、升級、監控等能力。

![至簡.png](https://ucc.alicdn.com/pic/developer-ecology/5ec24ec41fb94410a24deb69fc758e21.png)

由於外掛是“長”在 Service Mesh 之上的，外掛化的過程就是業務技術服務化的過程。

另外，Service Mesh 需要提供一種選擇能力，讓業務的應用開發者或運維者選擇自己的機器上需要哪些外掛（可以理解為外掛市場）。另一個值得關注的點是：外掛的運維和管理能力以及一定的質量保證手段由 Service Mesh 平臺提供，但運維、管理和質量保證的責任由各外掛的提供者承擔。這種劃分將有效地杜絕所有外掛的質量由 Service Mesh 平臺去承擔而帶來的低效，分而治之仍是改善很多工程效率的良方。

- **最後，Service Mesh 給探索麵向未來的異地多活、應用永遠線上的整體技術解決方案開啟了一扇大門。**

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

<a name="rPDIm" rel="nofollow"></a>
## Service Mesh 的“三位一體”發展思路
阿里巴巴作為雲端計算技術的供應商，在探索 Service Mesh 技術的道路上，不只是考慮如何讓雲原生技術紅利在阿里巴巴內部兌現，同時還思考著如何將技術紅利帶給更多的阿里雲客戶。基於此，阿里巴巴就 Service Mesh 的整體發展思路遵循“三位一體”，即阿里巴巴內部、阿里雲上的相應商業產品和開源軟體將採用同一套程式碼。

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

未來，我們將在 Service Mesh 領域堅定而紮實地探索，也一定會將探索成果和思考持續地分享給大家。

**本書亮點**

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

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247487974&idx=1&sn=4c5c63f090487ade029455e7b105cceb&chksm=fae51a29cd92933f10344c1f1d8de95b304ae50d656de1a5934d08852c1946970fd2fbc46d04&token=70445706&lang=zh_CN#rd)微信公眾號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公眾號。”

Service Mesh 是新瓶裝舊酒嗎？

相關文章