簡介：過去一年，阿里巴巴在 Service Mesh 的探索道路上依舊扎實前行，這種堅定并非只因堅信 Service Mesh 未來一定是云計算基礎(chǔ)技術(shù)的關(guān)鍵組成部分，還因需要借這一技術(shù)趨勢去償還過去所積累下來的技術(shù)債（“技術(shù)債”并非貶義詞，是技術(shù)發(fā)展的固有產(chǎn)物），基于當下的技術(shù)思潮和最佳實踐面向未來做出技術(shù)的新價值和新體驗。

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

過去一年，阿里巴巴在 Service Mesh 的探索道路上依舊扎實前行，這種堅定并非只因堅信 Service Mesh 未來一定是云計算基礎(chǔ)技術(shù)的關(guān)鍵組成部分，還因需要借這一技術(shù)趨勢去償還過去所積累下來的技術(shù)債（“技術(shù)債”并非貶義詞，是技術(shù)發(fā)展的固有產(chǎn)物），基于當下的技術(shù)思潮和最佳實踐面向未來做出技術(shù)的新價值和新體驗。

每當我們深入探索和實踐一項新技術(shù)時，大多情形下會步入一段“無聊”時期，期間每天面對的并非技術(shù)之新如何詮釋，而是如何先處理好技術(shù)債所帶來的羈絆，以及務實地給業(yè)務創(chuàng)造新價值和新體驗，通過攜手業(yè)務共贏的方式推動新技術(shù)落地。本文總結(jié)了過去一年 Service Mesh 在阿里巴巴的建設(shè)成果和收獲的洞察。

兌現(xiàn)增量業(yè)務價值是發(fā)展之本

Serivce Mesh 作為一種平臺型的新基礎(chǔ)技術(shù)，發(fā)展過程中一定回避不了兌現(xiàn)（增量）價值這個關(guān)鍵問題。從技術(shù)的角度，很容易理解將框架思維下 SDK 中的易變內(nèi)容下沉到 Service Mesh 中的 Sidecar 后，將促進中間件技術(shù)以業(yè)務無感的形式快速演進和升級，以平臺化和體系化的思維替代過去“山頭林立”的框架思維去進一步探索分布式應用構(gòu)架問題的更優(yōu)解，背后的價值并不容易被挑戰(zhàn)。

從業(yè)務的角度，采納新技術(shù)的關(guān)鍵是能解決當下的什么痛點、是否帶來機器成本的顯著降低、能否讓穩(wěn)定性有明顯的提升、運維和研發(fā)效率有否變得更高，這些收益被總稱為業(yè)務價值——業(yè)務視角下所看到的收益。發(fā)展 Service Mesh 很重要的一點是必須回歸兌現(xiàn)（增量）業(yè)務價值，圍繞不斷兌現(xiàn)業(yè)務價值去完善新技術(shù)，否則很難持續(xù)拿到階段性的成果。對于從事 Service Mesh 這類新技術(shù)建設(shè)的團隊來說，持續(xù)收獲階段性成果對于維持團隊士氣致關(guān)重要，建設(shè)者會因為業(yè)務價值足夠而能體會到“被需要”的感覺，進一步強化對自己工作價值的認可。

過去一年，我們經(jīng)歷了從“先做大規(guī)模落再兌現(xiàn)業(yè)務價值”到“先兌現(xiàn)業(yè)務價值再做大規(guī)模”的發(fā)展策略調(diào)整。在做大規(guī)模為先的階段，落地 Service Mesh 被挑戰(zhàn)的主要問題有三個：其一，增量業(yè)務價值不足，只是將 Java SDK 中已有的能力挪進了 Service Mesh；其二，資源開銷不可忽視；其三，技術(shù)成熟度不夠，沒能讓人看到工具化落地的問題定位與排錯手段。當確實不能回答好這三個問題時，推動 Service Mesh 在核心應用上的大規(guī)模落地就變得非常困難，即便有公司層面由上至下的助推也收效甚微。最終，不得不將發(fā)展策略調(diào)整為兌現(xiàn)價值為先。

在兌現(xiàn)價值的道路上，恰好某些業(yè)務團隊也從一開始挑戰(zhàn)上面三個問題變成了積極思考如何借 Service Mesh 化這次機會讓所在事業(yè)部的業(yè)務流量治理能力做一次重大升級。思路的轉(zhuǎn)變很快讓業(yè)務團隊錨定了業(yè)務痛點，與 Service Mesh 共創(chuàng)出了新的解決方案，最終兩個團隊的合作關(guān)系從甲乙方變成了你中有我、我中有你的戰(zhàn)友關(guān)系，大家一起抱團共贏。

回顧過去一年的經(jīng)歷，能得到的啟示是：

• 無論什么新技術(shù)，先做出增量業(yè)務價值才能更好地落地推廣。再先進的技術(shù)在沒有兌現(xiàn)增量價值之前都只是個愿景，但愿景并不那么容易讓人買單，技術(shù)落地依然要尊重市場規(guī)律。此外，新技術(shù)的成熟需要時間這是自然規(guī)律，技術(shù)成熟的過程中如果沒有兌現(xiàn)增量業(yè)務價值，則沒有業(yè)務甘愿只成為純粹的小白鼠。
• 基礎(chǔ)技術(shù)的發(fā)展不能只依靠基礎(chǔ)技術(shù)團隊的力量，業(yè)務團隊以積極的心態(tài)參與尋求解決業(yè)務痛點將成為強勁的新技術(shù)“催熟劑”。基礎(chǔ)技術(shù)團隊并沒有業(yè)務體感，而業(yè)務團隊的全情投入就能很好地彌補這一短板，兩者聯(lián)合所形成的化學反應就能帶來共贏的局面，合作關(guān)系也將升華至“戰(zhàn)友級”。基礎(chǔ)技術(shù)團隊需要特別重視與業(yè)務團隊合作，避免步入閉門造車的境況。

無侵入方案是關(guān)鍵手段但并非終態(tài)

在技術(shù)進化的過程中，我們希望盡可能做到兌現(xiàn)價值之時業(yè)務沒有任何的改造成本，這一點能很好地理解為何 Istio 推出至今采用了 iptables 做流量劫持。阿里巴巴在探索的過程中深知無侵入方案的價值，早在內(nèi)部落地時采用的也是無侵入方案，過去一年更進了一步讓無侵入方案支持流量透傳功能。

去年初，阿里巴巴內(nèi)部落地 Service Mesh 的技術(shù)方案并沒有考慮百分百做兼容。因為歷史原因，Dubbo 的序列化協(xié)議存在 Hessian2、Java 和其他小眾的選擇。考慮到 Hessian2 是主流協(xié)議，所以 Service Mesh 只對這一協(xié)議進行了支持。在落地的過程中，只要被 mesh 化的應用需要調(diào)用使用了不支持序列化協(xié)議的應用，就會直接導致該應用無法 Service Mesh 化。進一步，Service Mesh 的整體能力建設(shè)依賴這一技術(shù)點的突破，通過上量獲得更為廣泛的場景去兌現(xiàn)價值或為大規(guī)模落地打好基礎(chǔ)。比如，運維面支持大規(guī)模就屬于后者。另外，當所有應用都能 mesh 化時，最不濟也能在使用了 Hessian2 序列化的鏈路上兌現(xiàn)價值，而不致于因為應用無法 mesh 化而使得能兌現(xiàn)價值的鏈路變得更短（價值被弱化）。

為此，Service Mesh 需要全面“支持”所有 RPC 序列化協(xié)議。下圖示例了進一步的解決方案，圖中示例了 A、B 和 C 三個應用，其中 A 是被 mesh 化了的。需要指出，Sidecar（Envoy）在原有的基礎(chǔ)上增加了透傳功能，對于 Hessian2 之外的協(xié)議只收集必要的統(tǒng)計信息后透傳。需要補充的背景信息是，Service A 所使用的 RPC SDK 是全功能的，仍然具有服務治理能力。換句話說，SDK 做完路由所發(fā)出的包到達 Sidecar 后直接透傳就能保證服務的連通性。

長遠來看，對于 Dubbo 這種包含服務治理能力的 RPC 協(xié)議來說無侵入方案一定不是終態(tài)。原因在于，Dubbo SDK 需要有能力感知自己是否應工作于 Servcie Mesh 模式，在這種模式下將服務治理等職責下放給 Sidecar 去完成，從而省去 SDK 在這方面的內(nèi)存和 CPU 開銷。

基于此，過去一年阿里巴巴內(nèi)部圍繞終態(tài)的云原生方案也投入了相當?shù)牧α孔鼋ㄔO(shè)，讓 Service Mesh 能很好地與 Dubbo 3.0?一起協(xié)同工作。下圖示例說明了 Dubbo 3.0?下的 Service Mesh。

在終態(tài)方案中，Dubbo 3.0 SDK 有一個重大的變化是針對 Service Mesh 改善了友好度，整體設(shè)計考慮了云原生浪潮這一重大技術(shù)趨勢。與 Service Mesh 相關(guān)的主要變化是：

協(xié)議頭采用基于 gRPC 實現(xiàn)的 Triple 協(xié)議。通過將 Sidecar 需要感知或變更的內(nèi)容放到協(xié)議頭中，完全規(guī)避需要對消息體做反序列化和序列化的動作，消息體采用什么序列化協(xié)議對于 Sidecar 完全無感。

具備因 Service Mesh 出現(xiàn)故障的容災能力。Dubbo 3.0 SDK 具備 Thin 和 Fat 兩種模式，分別對應于工作于 Service Mesh 和非傳統(tǒng)模式。Thin SDK 下 CPU 和內(nèi)存的開銷將降到最低，所節(jié)省下來的開銷騰出來給 Sidecar 使用。Fat SDK 模式下則具備全面的路由治理能力，當 Service Mesh 出現(xiàn)故障時由 SDK 負責完成服務調(diào)用路由。

Service Mesh 模式下服務注冊與反注冊由 Sidecar 負責代理完成。換句話說，當 SDK 工作于 Service Mesh 模式時，SDK 完全感知不到后端的注冊中心，使得 Service Mesh 能最大程度地屏蔽下面的基礎(chǔ)設(shè)施細節(jié)。

去除了 iptables 做流量劫持，SDK 直接通過本機的進程間通訊（TCP/IP 網(wǎng)絡(luò) loopback 或 Unix Domain Socket）方式與 Sidecar 通訊。流量劫持能力的價值在于，SDK 可以在完全不升級的情形下由 Service Mesh 完成流量治理并對業(yè)務無感，由于 Dubbo 3.0?本來就存在 SDK 升級的問題，為了在穩(wěn)定性和性能上不引入新的問題而去除了 iptables。

值得強調(diào)，SDK 能回切至 Fat SDK 模式承擔起 Service Mesh 故障時的服務調(diào)用路由的前提假設(shè)是：Service Mesh 與 SDK 具有基本的對等能力，確保滿足容災場景下的基本需求。長遠來看，Service Mesh 的服務治理演進速度一定比 SDK 更快，如果有些功能與容災能力相關(guān)則需要在 SDK 中再實現(xiàn)。當然，Service Mesh 應當系統(tǒng)性地保障穩(wěn)定性，將 SDK 的保障能力放在單機維度而非全應用集群維度。

最后，正如前面所提到的，Service Mesh 的發(fā)展是需要業(yè)務方參與的，通過解決業(yè)務痛點去更好地牽引新技術(shù)落地。但凡為了解決業(yè)務問題，則一定程度地存在業(yè)務改造的需要，進一步表明無侵入方案無法從始至終地支撐好業(yè)務價值兌現(xiàn)這事。換句話說，準備落地 Service Mesh 的業(yè)務方，不應當將引入 Service Mesh 是否存在業(yè)務改造當作是一個核心考量點。業(yè)務改造從來都不是問題，問題在于改造有沒有解決業(yè)務痛點、有沒有讓技術(shù)升級到更高的層次為將來業(yè)務的發(fā)展打好基礎(chǔ)，而這一點本來就是業(yè)務落地 Service Mesh 時需要認真思考的。當然，就我們的經(jīng)驗來看，通過無侵入方案讓業(yè)務無感試水 Serivce Mesh 是非常推薦的實踐。對于同行來說，如果你所在的企業(yè)在探索 Service Mesh 或云原生相關(guān)技術(shù)，同時需要兼顧新老應用的連通和向新技術(shù)的漸進式演進，那到無侵入方案會是一個很好的過渡選擇。

正在兌現(xiàn)的增量業(yè)務價值

剛過去的一年，Service Mesh 在阿里巴巴內(nèi)部找到了二大增量業(yè)務價值兌現(xiàn)點。隨著建設(shè)工作將在接下來的幾個月全面完成，將迎來 十萬級應用實例的大規(guī)模落地。

增量業(yè)務價值兌現(xiàn)點之一，將國際化中臺當下的區(qū)域化和多租路由治理能力下沉至 Service Mesh，實現(xiàn)流量路由治理統(tǒng)一和應用級機房容災。過去，國際化中臺的 Java 應用是以 Annotation 的形式去指定應運用的路由策略，但凡需要變更路由策略就得做代碼修改并重新將應用發(fā)布上線，整個過程相當周折。還有，國際化中臺的容災只能做到機房級別，切流時需要將整個機房的流量全部切走。

引入 Service Mesh 后，將 Java 應用中通過 Annotation 指定路由策略的能力完全去除，通過下放到 Service Mesh 中以配置化的形式實現(xiàn)，使得每一次應用路由策略變更只需動態(tài)下發(fā)新的 YAML 文件即可，完全做到了與應用徹底解耦。進一步，由于路由策略是應用維度的，可以方便地以應用為顆粒度做機房間切流，提升了容災的敏捷性和降低了切流風險。

國際化中臺作為業(yè)務方，與 Service Mesh 團隊抱團探索業(yè)務價值的過程中非常積極主動地思考如何最大程度地發(fā)揮這次難得的技術(shù)升級機會。將過去存在單點服務治理能力的組件全面放到 Service Mesh 的 Sidecar 中以分布式的形式完成，不僅卸下了過往的運維包袱，還讓整體的業(yè)務穩(wěn)定性向前邁進了一大步。

增量業(yè)務價值兌現(xiàn)點之二，將 Service Mesh 靈活的流量治理能力運用于新零售事業(yè)群的開發(fā)環(huán)境治理，根據(jù)開發(fā)同學的需要動態(tài)創(chuàng)建相互獨立的開發(fā)環(huán)境。為了支撐好開發(fā)工作，阿里巴巴內(nèi)部的實踐是搭建了與生產(chǎn)環(huán)境完全獨立的日常環(huán)境，將線上的應用部署到兩個環(huán)境中用于每一個應用的開發(fā)調(diào)試工作。在日常環(huán)境中的每一個應用都可能因為開發(fā)的需要而進行變更，為了解耦應用間的相互影響又進一步在日常環(huán)境中又建立了基線環(huán)境，每個應用的開發(fā)工作都得基于基線環(huán)境所隔離出的開發(fā)環(huán)境完成開發(fā)工作，而不能直接將基線環(huán)境用于開發(fā)聯(lián)調(diào)。當應用數(shù)和開發(fā)人員的數(shù)量都數(shù)以萬計、每天的應用變更數(shù)數(shù)以千計時，如何保障好開發(fā)同學日常所需的開發(fā)環(huán)境就是很有挑戰(zhàn)和很有價值的一件事。

由于過去的開發(fā)環(huán)境隔離技術(shù)是基于框架思維去設(shè)計的，需要不同的流量（比如， RPC、消息、緩存和數(shù)據(jù)庫）從協(xié)議層面去對接同一個隔離框架，演進與維護相當困難。當存在多語言場景時，主要圍繞 Java 語言構(gòu)建的能力就使不上勁。另外，在沒有 Service Mesh 這樣的平臺技術(shù)出現(xiàn)時，有些隔離場景相當難實現(xiàn)。

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

上圖中，需要下發(fā) YAML 文件對特定的流量和應用進行打標。Envoy 則根據(jù)流量標將流量導到打了同樣標的機器上，當對應的標并沒有機器時，則運用回退機制讓流量回流到基線環(huán)境中。比如，開發(fā)環(huán)境 1 中的應用 B 調(diào)用應用 C 時，由于找不到打了 tag1 的機器則直接將流量打到基線環(huán)境。

可以預見，Service Mesh 所構(gòu)建的這一能力為將來探索 Test in Production 打開了一扇門。未來基于 Service Mesh 所構(gòu)建的流量隔離環(huán)境將有助于節(jié)約搭建獨立開發(fā)環(huán)境所需投入的機器成本，也為探索新一代的安全生產(chǎn)環(huán)境提供了新思路。當然，在這條路上我們?nèi)沃囟肋h。

截止本文完稿之時，阿里巴巴集團內(nèi)部 Service Mesh 的落地規(guī)模已達數(shù)萬應用實例。數(shù)據(jù)、控制和運維三大平臺的能力建設(shè)完全做到了具備大規(guī)模運用水平。

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

作者借此機會分享自己所理解的軟件生命周期理論，希望在云原生這一難得的技術(shù)浪潮之下該理論有助于讀者更好地看待新技術(shù)的發(fā)展并在這個過程中抓住機遇。

以靜態(tài)的思維看待軟件開發(fā)，極有可能最終導致所獲得的軟件是一個臃腫、易出錯的包袱。出現(xiàn)這種狀況的原因，是因為沒有明白軟件是存在生命周期的。軟件也象人一樣，存在形成、成長、成熟和衰退四大時期（如下圖所示）。圖中縱座標代表軟件對新需求的適應能力，指軟件對實現(xiàn)新需求的友好度，背后是概念與概念之間的關(guān)系是否清晰、讓人對其的認識是否符合直覺與常識，本質(zhì)是指軟件的設(shè)計質(zhì)量。圖中的直線也只代表一種趨勢，現(xiàn)實中更多地表現(xiàn)為存在波動的曲線。

軟件進入成熟期的標志，是其功能實現(xiàn)程度與當初的定位和使用場景契合。進入衰退期是因為業(yè)務發(fā)展的需要而出現(xiàn)了新的場景，此時軟件的概念抽象（又可以稱之為“架構(gòu)”或“主導軟件設(shè)計”）對于實現(xiàn)新場景下的需求并不友好，導致新開發(fā)的代碼變成了“貼狗皮膏藥”。軟件長期處于衰退期的副作用是，軟件質(zhì)量持續(xù)變差，開發(fā)同學的編碼體驗不斷下降。

理解軟件生命周期的另一種視角是，軟件工程師對于需求的理解是隨著時間逐步加深的，很難出現(xiàn)最初的軟件設(shè)計能滿足業(yè)務發(fā)展的長期需要，畢竟業(yè)務也是一天天變得復雜起來的。換句話說，軟件進入衰退期是不可避免的，而技術(shù)債也是軟件發(fā)展的自然產(chǎn)物。

走出衰退期的關(guān)鍵是需要讓軟件進入新一輪的生命周期，而最直接的辦法就是“還技術(shù)債”，其中包含了重構(gòu)、或用全新的思路與新技術(shù)去解決問題。從小處說來，工程師通過持續(xù)重構(gòu)去還技術(shù)債是真正鍛煉能力的時候，這個過程會基于個體對業(yè)務（或需求）的理解做重新的概念抽象，掌握良好的軟件設(shè)計能力正是從這些“小處”習得的，也只有具備良好軟件設(shè)計能力的工程師才有可能駕馭大型軟件系統(tǒng)的設(shè)計。

軟件生命周期理論告訴我們，一個好軟件并非一直能保持不變，而是能經(jīng)得起各種改變。當然，各種改變的背后需要以工程能力做支撐，全面通過單元測試、集成測試、系統(tǒng)測試等手段去保障軟件的質(zhì)量，一旦缺失了這些手段就很難建立起對改變的信心，也最終會趨向于固步自封地不變。

對于類似 Service Mesh 這樣的平臺型技術(shù)來說，都需要非常小心地應對軟件生命周期理論。平臺思維是為了解決通用問題，在通用和定制之間找到平衡。當平臺技術(shù)自身并不能很好地適應技術(shù)或業(yè)務發(fā)展的需要而快速演進時，自然將成為業(yè)務發(fā)展道路上的阻力而非助力。

結(jié)束語

接下來的一年，我們將持續(xù)地探索 Service Mesh 的價值，在兌現(xiàn) RPC 流量治理價值的同時，完成 RocketMQ 等的 Service Mesh 化，進一步延展 Service Mesh 的流量治理能力并兌現(xiàn)更多的增量業(yè)務價值。

我們致力于解決阿里巴巴內(nèi)部基礎(chǔ)技術(shù)的 Service Mesh 化，因為以阿里巴巴自身的業(yè)務規(guī)模來看更需要 Service Mesh 。接下來，我們也將與更多業(yè)界同仁進行交流，期待通過分享所收獲的經(jīng)驗與客戶手牽手堅實地進入云原生時代。

如果讀者有交流的需求，或者希望成為阿里巴巴 Service Mesh 的建設(shè)者之一，請來信至 zhijian.ly@alibaba-inc.com。

原文鏈接：https://developer.aliyun.com/article/783605?

版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔相應法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。