本文節選自《不一樣的 雙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等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公衆号。”