Service Mesh 爲何從「趨勢」走向「無聊」？

簡介：過去一年，阿里巴巴在 Service Mesh 的探索道路上依舊紮實前行，這種堅決並不是只因堅信 Service Mesh 將來必定是雲計算基礎技術的關鍵組成部分，還因須要借這一技術趨勢去償還過去所積累下來的技術債（「技術債」並不是貶義詞，是技術發展的固有產物），基於當下的技術思潮和最佳實踐面向將來作出技術的新價值和新體驗。

做者 | 李雲（至簡）
來源 | 阿里巴巴雲原生公衆號

過去一年，阿里巴巴在 Service Mesh 的探索道路上依舊紮實前行，這種堅決並不是只因堅信 Service Mesh 將來必定是雲計算基礎技術的關鍵組成部分，還因須要借這一技術趨勢去償還過去所積累下來的技術債（「技術債」並不是貶義詞，是技術發展的固有產物），基於當下的技術思潮和最佳實踐面向將來作出技術的新價值和新體驗。

每當咱們深刻探索和實踐一項新技術時，大多情形下會步入一段「無聊」時期，期間天天面對的並不是技術之新如何詮釋，而是如何先處理好技術債所帶來的羈絆，以及務實地給業務創造新價值和新體驗，經過攜手業務雙贏的方式推進新技術落地。本文總結了過去一年 Service Mesh 在阿里巴巴的建設成果和收穫的洞察。

兌現增量業務價值是發展之本

Serivce Mesh 做爲一種平臺型的新基礎技術，發展過程當中必定迴避不了兌現（增量）價值這個關鍵問題。從技術的角度，很容易理解將框架思惟下 SDK 中的易變內容下沉到 Service Mesh 中的 Sidecar 後，將促進中間件技術以業務無感的形式快速演進和升級，以平臺化和體系化的思惟替代過去「山頭林立」的框架思惟去進一步探索分佈式應用構架問題的更優解，背後的價值並不容易被挑戰。

從業務的角度，採納新技術的關鍵是能解決當下的什麼痛點、是否帶來機器成本的顯著下降、可否讓穩定性有明顯的提高、運維和研發效率有否變得更高，這些收益被總稱爲業務價值——業務視角下所看到的收益。發展 Service Mesh 很重要的一點是必須迴歸兌現（增量）業務價值，圍繞不斷兌現業務價值去完善新技術，不然很難持續拿到階段性的成果。對於從事 Service Mesh 這類新技術建設的團隊來講，持續收穫階段性成果對於維持團隊士氣致關重要，建設者會由於業務價值足夠而能體會到「被須要」的感受，進一步強化對本身工做價值的承認。

過去一年，咱們經歷了從「先作大規模落再兌現業務價值」到「先兌現業務價值再作大規模」的發展策略調整。在作大規模爲先的階段，落地 Service Mesh 被挑戰的主要問題有三個：其一，增量業務價值不足，只是將 Java SDK 中已有的能力挪進了 Service Mesh；其二，資源開銷不可忽視；其三，技術成熟度不夠，沒能讓人看到工具化落地的問題定位與排錯手段。當確實不能回答好這三個問題時，推進 Service Mesh 在覈心應用上的大規模落地就變得很是困難，即使有公司層面由上至下的助推也收效甚微。最終，不得不將發展策略調整爲兌現價值爲先。

在兌現價值的道路上，剛好某些業務團隊也從一開始挑戰上面三個問題變成了積極思考如何借 Service Mesh 化此次機會讓所在事業部的業務流量治理能力作一次重大升級。思路的轉變很快讓業務團隊錨定了業務痛點，與 Service Mesh 共創出了新的解決方案，最終兩個團隊的合做關係從甲乙方變成了你中有我、我中有你的戰友關係，你們一塊兒抱團雙贏。

回顧過去一年的經歷，能獲得的啓示是：

• 不管什麼新技術，先作出增量業務價值才能更好地落地推廣。再先進的技術在沒有兌現增量價值以前都只是個願景，希望景並不那麼容易讓人買單，技術落地依然要尊重市場規律。此外，新技術的成熟須要時間這是天然規律，技術成熟的過程當中若是沒有兌現增量業務價值，則沒有業務甘願只成爲純粹的小白鼠。
• 基礎技術的發展不能只依靠基礎技術團隊的力量，業務團隊以積極的心態參與尋求解決業務痛點將成爲強勁的新技術「催熟劑」。基礎技術團隊並無業務體感，而業務團隊的全情投入就能很好地彌補這一短板，二者聯合所造成的化學反應就能帶來雙贏的局面，合做關係也將昇華至「戰友級」。基礎技術團隊須要特別重視與業務團隊合做，避免步入閉門造車的境況。

無侵入方案是關鍵手段但並不是終態

在技術進化的過程當中，咱們但願儘量作到兌現價值之時業務沒有任何的改形成本，這一點能很好地理解爲什麼 Istio 推出至今採用了 iptables 作流量劫持。阿里巴巴在探索的過程當中深知無侵入方案的價值，早在內部落地時採用的也是無侵入方案，過去一年更進了一步讓無侵入方案支持流量透傳功能。

去年初，阿里巴巴內部落地 Service Mesh 的技術方案並無考慮百分百作兼容。由於歷史緣由，Dubbo 的序列化協議存在 Hessian二、Java 和其餘小衆的選擇。考慮到 Hessian2 是主流協議，因此 Service Mesh 只對這一協議進行了支持。在落地的過程當中，只要被 mesh 化的應用須要調用使用了不支持序列化協議的應用，就會直接致使該應用沒法 Service Mesh 化。進一步，Service Mesh 的總體能力建設依賴這一技術點的突破，經過上量得到更爲普遍的場景去兌現價值或爲大規模落地打好基礎。好比，運維面支持大規模就屬於後者。另外，當全部應用都能 mesh 化時，最不濟也能在使用了 Hessian2 序列化的鏈路上兌現價值，而不致於由於應用沒法 mesh 化而使得能兌現價值的鏈路變得更短（價值被弱化）。

爲此，Service Mesh 須要全面「支持」全部 RPC 序列化協議。下圖示例了進一步的解決方案，圖中示例了 A、B 和 C 三個應用，其中 A 是被 mesh 化了的。須要指出，Sidecar（Envoy）在原有的基礎上增長了透傳功能，對於 Hessian2 以外的協議只收集必要的統計信息後透傳。須要補充的背景信息是，Service A 所使用的 RPC SDK 是全功能的，仍然具備服務治理能力。換句話說，SDK 作完路由所發出的包到達 Sidecar 後直接透傳就能保證服務的連通性。

長遠來看，對於 Dubbo 這種包含服務治理能力的 RPC 協議來講無侵入方案必定不是終態。緣由在於，Dubbo SDK 須要有能力感知本身是否應工做於 Servcie Mesh 模式，在這種模式下將服務治理等職責下放給 Sidecar 去完成，從而省去 SDK 在這方面的內存和 CPU 開銷。

基於此，過去一年阿里巴巴內部圍繞終態的雲原生方案也投入了至關的力量作建設，讓 Service Mesh 能很好地與 Dubbo 3.0 一塊兒協同工做。下圖示例說明了 Dubbo 3.0 下的 Service Mesh。

在終態方案中，Dubbo 3.0 SDK 有一個重大的變化是針對 Service Mesh 改善了友好度，總體設計考慮了雲原生浪潮這一重大技術趨勢。與 Service Mesh 相關的主要變化是：

協議頭採用基於 gRPC 實現的 Triple 協議。經過將 Sidecar 須要感知或變動的內容放到協議頭中，徹底規避須要對消息體作反序列化和序列化的動做，消息體採用什麼序列化協議對於 Sidecar 徹底無感。

具有因 Service Mesh 出現故障的容災能力。Dubbo 3.0 SDK 具有 Thin 和 Fat 兩種模式，分別對應於工做於 Service Mesh 和非傳統模式。Thin SDK 下 CPU 和內存的開銷將降到最低，所節省下來的開銷騰出來給 Sidecar 使用。Fat SDK 模式下則具有全面的路由治理能力，當 Service Mesh 出現故障時由 SDK 負責完成服務調用路由。

Service Mesh 模式下服務註冊與反註冊由 Sidecar 負責代理完成。換句話說，當 SDK 工做於 Service Mesh 模式時，SDK 徹底感知不到後端的註冊中心，使得 Service Mesh 能最大程度地屏蔽下面的基礎設施細節。

去除了 iptables 作流量劫持，SDK 直接經過本機的進程間通信（TCP/IP 網絡 loopback 或 Unix Domain Socket）方式與 Sidecar 通信。流量劫持能力的價值在於，SDK 能夠在徹底不升級的情形下由 Service Mesh 完成流量治理並對業務無感，因爲 Dubbo 3.0 原本就存在 SDK 升級的問題，爲了在穩定性和性能上不引入新的問題而去除了 iptables。

值得強調，SDK 能回切至 Fat SDK 模式承擔起 Service Mesh 故障時的服務調用路由的前提假設是：Service Mesh 與 SDK 具備基本的對等能力，確保知足容災場景下的基本需求。長遠來看，Service Mesh 的服務治理演進速度必定比 SDK 更快，若是有些功能與容災能力相關則須要在 SDK 中再實現。固然，Service Mesh 應當系統性地保障穩定性，將 SDK 的保障能力放在單機維度而非全應用集羣維度。

最後，正如前面所提到的，Service Mesh 的發展是須要業務方參與的，經過解決業務痛點去更好地牽引新技術落地。但凡爲了解決業務問題，則必定程度地存在業務改造的須要，進一步代表無侵入方案沒法從始至終地支撐好業務價值兌現這事。換句話說，準備落地 Service Mesh 的業務方，不該當將引入 Service Mesh 是否存在業務改造看成是一個核心考量點。業務改造歷來都不是問題，問題在於改造有沒有解決業務痛點、有沒有讓技術升級到更高的層次爲未來業務的發展打好基礎，而這一點原本就是業務落地 Service Mesh 時須要認真思考的。固然，就咱們的經驗來看，經過無侵入方案讓業務無感試水 Serivce Mesh 是很是推薦的實踐。對於同行來講，若是你所在的企業在探索 Service Mesh 或雲原生相關技術，同時須要兼顧新老應用的連通和向新技術的漸進式演進，那到無侵入方案會是一個很好的過渡選擇。

正在兌現的增量業務價值

剛過去的一年，Service Mesh 在阿里巴巴內部找到了二大增量業務價值兌現點。隨着建設工做將在接下來的幾個月全面完成，將迎來 十萬級應用實例的大規模落地。

增量業務價值兌現點之一，將國際化中臺當下的區域化和多租路由治理能力下沉至 Service Mesh，實現流量路由治理統一和應用級機房容災。過去，國際化中臺的 Java 應用是以 Annotation 的形式去指定應運用的路由策略，但凡須要變動路由策略就得作代碼修改並從新將應用發佈上線，整個過程至關周折。還有，國際化中臺的容災只能作到機房級別，切流時須要將整個機房的流量所有切走。

引入 Service Mesh 後，將 Java 應用中經過 Annotation 指定路由策略的能力徹底去除，經過下放到 Service Mesh 中以配置化的形式實現，使得每一次應用路由策略變動只需動態下發新的 YAML 文件便可，徹底作到了與應用完全解耦。進一步，因爲路由策略是應用維度的，能夠方便地以應用爲顆粒度作機房間切流，提高了容災的敏捷性和下降了切流風險。

國際化中臺做爲業務方，與 Service Mesh 團隊抱團探索業務價值的過程當中很是積極主動地思考如何最大程度地發揮此次可貴的技術升級機會。將過去存在單點服務治理能力的組件全面放到 Service Mesh 的 Sidecar 中以分佈式的形式完成，不只卸下了過往的運維包袱，還讓總體的業務穩定性向前邁進了一大步。

增量業務價值兌現點之二，將 Service Mesh 靈活的流量治理能力運用於新零售事業羣的開發環境治理，根據開發同窗的須要動態建立相互獨立的開發環境。爲了支撐好開發工做，阿里巴巴內部的實踐是搭建了與生產環境徹底獨立的平常環境，將線上的應用部署到兩個環境中用於每個應用的開發調試工做。在平常環境中的每個應用均可能由於開發的須要而進行變動，爲了解耦應用間的相互影響又進一步在平常環境中又創建了基線環境，每一個應用的開發工做都得基於基線環境所隔離出的開發環境完成開發工做，而不能直接將基線環境用於開發聯調。當應用數和開發人員的數量都數以萬計、天天的應用變動數數以千計時，如何保障好開發同窗平常所需的開發環境就是頗有挑戰和頗有價值的一件事。

因爲過去的開發環境隔離技術是基於框架思惟去設計的，須要不一樣的流量（好比， RPC、消息、緩存和數據庫）從協議層面去對接同一個隔離框架，演進與維護至關困難。當存在多語言場景時，主要圍繞 Java 語言構建的能力就使不上勁。另外，在沒有 Service Mesh 這樣的平臺技術出現時，有些隔離場景至關難實現。

Service Mesh 的價值在於，其天生就是爲了流量治理而生，動態且靈活地完成流量的隔離與路由是核心能力之一。咱們對 Istio 中的 VirtualService 和 DestinationRule 進行了擴展，抽象出了 TrafficLabel 這一全新的 CRD，經過下發 YAML 文件動態地對流量和應用機器進行打標，Envoy 則基於流量標和機器標進行路由，從而作到靈活又快速地構建出開發同窗所需的開發環境，且能很好地支持多語言應用。下圖示例說明了 Service Mesh 下，同時開發 v1.1 和 v1.2 兩個版本時的應用部署和流量拓撲。

上圖中，須要下發 YAML 文件對特定的流量和應用進行打標。Envoy 則根據流量標將流量導到打了一樣標的機器上，當對應的標並無機器時，則運用回退機制讓流量回流到基線環境中。好比，開發環境 1 中的應用 B 調用應用 C 時，因爲找不到打了 tag1 的機器則直接將流量打到基線環境。

能夠預見，Service Mesh 所構建的這一能力爲未來探索 Test in Production 打開了一扇門。將來基於 Service Mesh 所構建的流量隔離環境將有助於節約搭建獨立開發環境所需投入的機器成本，也爲探索新一代的安全生產環境提供了新思路。固然，在這條路上咱們任重而道遠。

截止本文完稿之時，阿里巴巴集團內部 Service Mesh 的落地規模已達數萬應用實例。數據、控制和運維三大平臺的能力建設徹底作到了具有大規模運用水平。

不可忽視的軟件生命週期理論

做者藉此機會分享本身所理解的軟件生命週期理論，但願在雲原生這一可貴的技術浪潮之下該理論有助於讀者更好地看待新技術的發展並在這個過程當中抓住機遇。

以靜態的思惟看待軟件開發，極有可能最終致使所得到的軟件是一個臃腫、易出錯的包袱。出現這種情況的緣由，是由於沒有明白軟件是存在生命週期的。軟件也象人同樣，存在造成、成長、成熟和衰退四大時期（以下圖所示）。圖中縱座標表明軟件對新需求的適應能力，指軟件對實現新需求的友好度，背後是概念與概念之間的關係是否清晰、讓人對其的認識是否符合直覺與常識，本質是指軟件的設計質量。圖中的直線也只表明一種趨勢，現實中更多地表現爲存在波動的曲線。

軟件進入成熟期的標誌，是其功能實現程度與當初的定位和使用場景契合。進入衰退期是由於業務發展的須要而出現了新的場景，此時軟件的概念抽象（又能夠稱之爲「架構」或「主導軟件設計」）對於實現新場景下的需求並不友好，致使新開發的代碼變成了「貼狗皮膏藥」。軟件長期處於衰退期的反作用是，軟件質量持續變差，開發同窗的編碼體驗不斷降低。

理解軟件生命週期的另外一種視角是，軟件工程師對於需求的理解是隨着時間逐步加深的，很難出現最初的軟件設計能知足業務發展的長期須要，畢竟業務也是一每天變得複雜起來的。換句話說，軟件進入衰退期是不可避免的，而技術債也是軟件發展的天然產物。

走出衰退期的關鍵是須要讓軟件進入新一輪的生命週期，而最直接的辦法就是「還技術債」，其中包含了重構、或用全新的思路與新技術去解決問題。從小處說來，工程師經過持續重構去還技術債是真正鍛鍊能力的時候，這個過程會基於個體對業務（或需求）的理解作從新的概念抽象，掌握良好的軟件設計能力正是從這些「小處」習得的，也只有具有良好軟件設計能力的工程師纔有可能駕馭大型軟件系統的設計。

軟件生命週期理論告訴咱們，一個好軟件並不是一直能保持不變，而是能經得起各類改變。固然，各類改變的背後須要以工程能力作支撐，全面經過單元測試、集成測試、系統測試等手段去保障軟件的質量，一旦缺失了這些手段就很難創建起對改變的信心，也最終會趨向於固步自封地不變。

對於相似 Service Mesh 這樣的平臺型技術來講，都須要很是當心地應對軟件生命週期理論。平臺思惟是爲了解決通用問題，在通用和定製之間找到平衡。當平臺技術自身並不能很好地適應技術或業務發展的須要而快速演進時，天然將成爲業務發展道路上的阻力而非助力。

結束語

接下來的一年，咱們將持續地探索 Service Mesh 的價值，在兌現 RPC 流量治理價值的同時，完成 RocketMQ 等的 Service Mesh 化，進一步延展 Service Mesh 的流量治理能力並兌現更多的增量業務價值。

咱們致力於解決阿里巴巴內部基礎技術的 Service Mesh 化，由於以阿里巴巴自身的業務規模來看更須要 Service Mesh 。接下來，咱們也將與更多業界同仁進行交流，期待經過分享所收穫的經驗與客戶手牽手堅實地進入雲原生時代。

若是讀者有交流的需求，或者但願成爲阿里巴巴 Service Mesh 的建設者之一，請來信至 zhijian.ly@alibaba-inc.com。

本文內容由阿里雲實名註冊用戶自發貢獻，版權歸原做者全部，阿里雲開發者社區不擁有其著做權，亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將馬上刪除涉嫌侵權內容。