過去一年，阿裡巴巴在 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 的建設者之一，請來信至 [email protected]。