作者 |?李云（至簡）
來源 | 阿里巴巴云原生公眾號

過去一年，阿里巴巴在 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 的序列化協議存在 Hessian2、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。

總結

以上是生活随笔為你收集整理的Service Mesh 从“趋势”走向“无聊”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。