過去一年，阿里巴巴在 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 。接下來，我們也將與更多業界同仁進行交流，期待通過分享所收穫的經驗與客戶手牽手堅實地進入雲原生時代。

作者 | 李雲（至簡）

本文爲阿里雲原創內容，未經允許不得轉載。