阿里云：2022微服務治理技術白皮書（377頁）.pdf

1、阿云研究員，云原應平臺負責 - 丁宇（叔同）在阿巴巴微服務架構 10 余年的演進歷程中，服務部署量不斷擴，已經邁百萬節點規模，如此龐的微服務體系必須要通過服務治理進精細化管控，提升線上業務穩定性。阿集團的服務治理框架從到有，經歷了服務框架提供治理 SDK、輕量級隔離容器 Pandora 、侵式的 Java Agent 以及針對異構微服務的 Service Mesh 等架構迭代歷程，這個過程中沉淀了豐富的服務治理能，涵蓋了開發、測試、線上運維、可等多個。這本技術書系統化的闡述了服務治理的演進路線以及落地最佳實踐，相信對企業開發者和架構師在采納微服務架構時能有所幫助。阿云資深技術專家，云原中間件負

2、責 - 胡偉琪（慕）阿巴巴作為國內微服務的先者，有著豐富的實踐經驗和技術積累，近年阿巴巴中間件團隊推三位體的技術戰略，把內部業務持、云產品、開源進了技術和架構的統，并開源了系列優秀的項，包括 Apache Dubbo，Apache RocketMQ、Nacos、SpringCloud Alibaba、Seata 等，為量企業進微服務化架構升級提供了助。本書是阿巴巴中間件團隊在微服務領域的又作，詳盡介紹了阿巴巴針對規模微服務場景下，進效治理的案和思想，推薦前有計劃或已經完成了微服務改造、對微服務領域技術有興趣的技術閱讀。阿云資深技術專家，云原 Serverless 及可觀測產品線負責 - 司徒放

3、（姬）在微服務架構已經其道的今天，為什么我們要談微服務治理？就像斯洛需求模型所述，類的需求是理、安全、社交、尊重和我成就的逐步實現。類似的，企業實施微服務架構的過程也遵循著同樣的道理。微服務架構，第階段要解決服務間的發現問題和相互通信問題，這是微服務框架所覆蓋的基本功能。第階段要解決微服務應的交付和規?；\維問題，這些是容器和 K8s 所擅的領域。第三階段隨著微服務架構復雜化，分布式場景下排查和診斷效率急劇下降開始成為開發者主要痛點，因此催了分布式鏈路跟蹤和可觀測性技術。正所謂“亂極必治”，微服務架構是把雙刃劍，規模之下掩蓋的問題很多，從開發聯調到發布上線，從流量防護到故障恢復再到容災，如果不

4、引恰當的治理段，很可能會積重難返、萬劫不復。因此微服務治理是微服務演進的第四個必然階段，微服務治理得到重視是恰逢其時。推薦序推薦序Alibaba Cloud Alibaba Cloud Microservices Governance Technology阿巴巴從 2008 年開始踐微服務，阿中間件團隊也路伴隨著過了上述個階段，是微服務架構發展的親歷者。這本書來中間件團隊對微服務最有經驗的那個之，也是阿微服務開源 Dubbo、Spring Cloud Alibaba、Nacos 等項的主要創作者。他們結合了阿身的微服務實踐，以及中間件上云之后服務外部企業客戶的第案例，我認為本書論從內容的豐富度

5、，還是經驗的普適性來看，都是國內最有參考價值的份微服務架構材料。將本書誠摯推薦給每個希望在企業 內應微服務架構的架構師、以及對微服務有興趣的愛好者閱讀。阿里云高級技術專家，云原生解決方案負責人 - 邱戈川（了哥）軟件技術的發展，從單體的應用，逐漸演進到分布式應用， 特別是微服務理念的興起，讓大規模、高并發、低延遲的分布式應用成為可能。但是微服務架構不是銀彈， 其維護的復雜度，以及管理、治理的難度超過以往的任何系統架構。而阿里巴巴/阿里云中間件團隊是這個領域的先行者，通過多年的阿里巴巴內部演進與支持，以及與大量的阿里云外部客戶的共同努力，沉淀出在業界領先的微服務領域特別是服務治理上的一套方法論以

6、及最佳實踐。這本白皮書，正是微服務治理方法論以及最佳實踐的歸納與總結，可以幫助大家在微服務架構設計與管理上提供很好的借鑒與參考。特別是其獨特的類似 Mesh 的理念在容器下結合 Java Agent 模式，很好的解決了 Java 領域提供無侵入式增強治理能力如限流降級、全鏈路灰度、可觀測性增強等問題，同時又巧妙的規避了升級、版本不一致等等維護的代價。如果你正好采用微服務架構來完善自己的應用體系，這個白皮書絕對值能幫助你完善你的架構設計，為你的業務穩定運行提供技術架構保障，強烈推薦！上海三菱電梯，系統開發總監 - 謝璟云原時代，軟件架構，軟件框架都經歷速的發展。從最早期 Eureka，到前國內以

7、 Nacos為的微服務態，阿巴巴為此作出了卓越貢獻。在和阿云和阿巴巴合作過程中，深深感受到阿云的技術氛圍和底蘊，通過侵的 Java Agent ，全代碼零侵，提供了縫切換阿微服務治理技術案。阿云的服務治理的模型，依托阿云堅實的底座，結合阿云云上資源，使得我們能夠快速融阿云服務治理，形成統，標準，最佳的微服務治理案。微服務治理技術，思想，解決案，最佳實踐都在本書有詳細的闡述，是值得每個技術員認真品讀的好書。Microservices Governance Technology來電科技 CTO - 羅昌明來電科技擁有百萬級的物聯網終端，中后臺微服務化后擁有數百個微服務組件，管理這些微服務是個極其復

8、雜的工程。阿里云 MSE 微服務治理技術幫助來電無侵入地實現了服務預熱、無損上下線、全鏈路灰度等微服務治理能力，大大提升了服務的穩定性。如果你正準備深入微服務治理相關知識或者遇到相同問題，那么這本書正好可以提供深入學習的機會。Salesforce 中國，技術總監 - 葉文帥隨著業務的發展和團隊擴大，微服務架構成為了許多大規模開發團隊的不二選擇。在微服務架構發展的過程中，我們經歷了從傳統分布式微服務框架治理到云原生微服務治理的演變。伴隨著服務數量的增多以及對服務穩定性要求的提高，社區上和公有云上都誕生了許多優秀的微服務治理工具。阿里云中間件團隊針對開發者們在微服務開發中遇到的痛點，結合阿里云生態

9、，在本書講述了云原生下微服務治理架構的設計以及微服務治理的最佳實踐。相信這本白皮書能給企業中微服務架構師，以及對微服務架構有興趣的開發者帶來幫助。Microservices Governance Technology第章：綜述11.1 業務發展離不開微服務治理保駕護航11.2 微服務治理在云原場景下的挑戰71.3 微服務治理的發展趨勢111.4 微服務治理的區分18第章：微服務治理技術原理介紹212.1 微服務治理技術概述212.2 通過 SDK 式進微服務治理232.3 通過 Java Agent 式進微服務治理252.4 通過 Service Mesh 來進微服務治理28第三章：微服務治理

10、在云原場景下的解決案333.1 線上發布穩定性解決案333.2 微服務全鏈路灰度解決案433.3 微服務可觀測增強解決案563.4 微服務應配置解決案693.5 微服務限流降級解決案763.6 微服務開發測試提效解決案853.7 微服務敏捷開發解決案903.8 微服務縫遷移上云解決案953.9 線上故障緊急診斷、排查與恢復1033.10 微服務注冊發現可解決案1133.11 微服務應安全解決案1183.12 異構微服務互通解決案1223.13 微服務 Serverless PaaS 解決方案125CONTENTCONTENTAlibaba Cloud Alibaba Cloud Microse

11、rvices Governance TechnologyMicroservices Governance Technology128129146165183199221245262272277289306319330339339346357363368第四章：基于 MSE 的微服務治理最佳實踐4.1 線上發布穩定性解決案最佳實踐4.2 全鏈路灰度最佳實踐4.2.1 Ingress-nginx 全鏈路灰度4.2.2 Zuul 和 Spring Cloud Gateway 全鏈路灰度4.2.3 MSE 云原關全鏈路灰度4.2.4 全鏈路灰度之 RocketMQ 灰度4.2.5 使Jenkins C

12、I/CD 實現絲雀發布4.3 微服務應配置最佳實踐4.4 微服務限流降級最佳實踐4.5 微服務開發測試提效最佳實踐4.6 微服務敏捷開發最佳實踐4.7 微服務縫遷移上云實踐4.8 如何快速構建服務發現的可能4.9 如何在 Serverless 模式下快速使用服務治理能力第五章：微服務治理客戶案例5.1 物流行業：菜 Cpaas 平臺微服務治理實踐5.2 互聯網行業：來電科技微服務治理實踐5.3 機器智能行業：云小蜜 Dubbo3 微服務治理實踐5.4 游戲行業：廣州小邁微服務治理實踐第六章：總結與展望總結與展望368作者按照姓名拼音升序排序作者作者Microservices Governanc

13、e TechnologyAlibaba Cloud Alibaba Cloud 白壯麗 - 竹達曹玲微 - 陌微曹茵茵 - 蔓鈴陳飛 - 麒汀陳濤 - 畢衫陳昕 - 捌哥范揚 - 揚少魯嚴波 - 卜比泮圣偉 - 十眠饒子昊 - 鋮樸蘇宇 - 流士湯長征唐慧芬 - 黛忻王桐 - 瑾涵肖京 - 亦盞葉辰超 - 楚寰張海彬 - 古琦張乎興 - 望陶張偉 - 柑橘張哲 - 溪岳趙俊陽 - 墨昀趙奕豪 - 宿何方劍 - 洛夜徐靖峰 - 島風Microservices Governance Technology1第章：綜述1.1 業務發展離不開微服務治理保駕護航微服務開發不簡單隨著微服務技術的發展，微服務

14、(MicroServices) 的概念早已深，也越來越多的公司開始使微服務架構來開發業務應。如果采得當，微服務架構可以帶來常的優勢。微服務架構的最好處是它可以提升開發效率和系統整體的穩定性：開發和部署相對簡單：單個微服務的功能可以更快地更改，因為可以獨部署，影響范圍更，啟動和調試單個微服務的時間成本相于單體應也減少。橫向擴展簡單：根據業務的峰低周期快速的橫向擴展常簡單，因為單個微服務通常很，可以隨著系統整體負載的變化更快地啟動和停。架構升級靈活：單個微服務的內部架構可以迅速升級，因為微服務之間松散耦合的，只向定義好的通訊接進編程。這使開發團隊能夠基于身的技術背景和偏好靈活選擇，不會直接影響其他

15、應程序、服務或團隊。更好的容錯性：微服務之間可以實現更好的故障隔離，單個服務內的內存泄露等故障不容易影響其他服務，相單體應個組件故障會拖垮整個系統。但是微服務在實施過程中，也很容易遇到些難點。如果微服務治理得不恰當，反有可能適得其反，不僅不能享受到微服務架構帶來的好處，反會因為微服務帶來的系統復雜性，造成開發、運維部署的復雜度增加，進影響開發迭代的速度，甚影響系統的整體穩定性。2我們總結了些微服務開發實施過程中常的問題：服務之間使遠程調進通訊， 這進程內的直接調復雜很多。 由于通訊鏈路的復雜性，可能會出現很多不確定的問題，會出現遠程調不可或者延遲較的情況，開發員需要能夠處理這些偶發問題，避免影

16、響業務。隨著業務的發展，微服務之間的拓撲圖開始變得復雜，排查問題變得困難，搭建完整的開發測試環境成本也越來越。當功能涉及到多個微服務模塊時，迭代時需要謹慎地協調多個開發團隊的迭代排期，才能保證迭代能夠按時交付，達到敏捷開發的效果。Microservices Governance Technology個微服務成功落地的典型案例觀察了阿云眾多客戶之后，我們總結抽象了個微服務成功落地的典型案例，敘述了某公司是如何借助于微服務架構的紅利，實現了業務快速增的。案例詳細說明了在業務發展的不同階段，該公司在微服務實施過程遇到的問題，也描述了如何通過微服務治理來解決這些問題，從享受到了微服務帶來的開發效率和業

17、務穩定性提升的紅利，進促進業務快速發展。業務孵化期初創公司在剛起步時，雖然業務量較、業務模式較簡單，但是為了在后續的快速發展中能夠快速迭代，同時公司的才儲備也滿微服務開發的條件，于是在初創期就選擇了使微服務架構進業務開發。在技術選型，如果公司創始員是技術出身，那么會較傾向于使擅的微服務框架，如創始是 Dubbo 的 contributor ，或者是 Spring Cloud 社區的咖或者 SpringCloud Alibaba 的 contributor， 又或者是 Service Mesh 社區的咖， 那么般都會選所擅的微服務框架類型。還有種選擇是選市上最流的微服務框架，如 Java 體系，

18、會選擇 SpringCloud 和 Dubbo。這樣的話，在前的招聘市場上也容易招聘到熟悉相關領域的，從初學者到專家級的候選都能很容易招聘到。選定了技術選型后，基于開源的框架，很容易就能開發好最初的業務應系統，跑通業務流程。這階段組件也很簡單。簡單的兩三個應，戶系統、業務系統、持系統，再加上注冊中31.因為代碼本身邏輯出錯導致業務異常：這時可以通過 SLS 查詢志，結合 ARMS 分析錯誤堆棧找到根因，修改完代碼后，重新發布來修復問題。2.遇到性能瓶頸：則直接擴容操作，如平擴容應，或者升級數據庫。3.發布新版本影響到戶：因為戶數和請求數都不算多，很容易就可以找到業務低峰期，在業務低峰期進發布。

19、4.如何確保新版本的正確性，因為業務場景不復雜，內部測試就能覆蓋所有的場景，測試通過就可以直接上線。那如何識別身的業務是否處于這個階段呢？有系列典型的特征：應不超過 4 個，應節點總數不超過 10 個，最峰時候的 QPS 不超過 10。業務快速發展期在活過初創期之后，公司的業務很受戶和市場的歡迎，注冊的戶越來越多，戶使的時和功能點也越來越多，活數越來越，甚市場中還出現了其他競爭者開始抄襲公司的業務，一些巨頭還親下場參與競爭。公司業務發展得常順利，這也意味著系統進了快速發展時期。Microservices Governance Technology、數據庫、緩存，就可以開發完全部的應。對于個產級

20、別的系統來說，在將整套系統部署上線之前，還需要建設監控報警系統。監控報警系統能夠幫助我們實時監控機器和應的狀態。我們可以配置預設的報警規則，在出現機器資源不，業務出現異常報錯時這些情況時主動報警，提醒我們盡快處理系統中的險和異常。保留問題的現場，并幫助我們快速地定位和排查問題也同樣重要，阿云應實時監控服務 ARMS 和志服務 SLS 能夠在這些場景提供很的幫助。采 ARMS + SLS 完成監控報警系統建設之后，將業務系統部署上線，完成第次成功上線，業務開始正常運起來了。但是業務的開發和運營從來都不是帆順的，在這個過程中，肯定也會遇到很多問題，我們先總結下這個階段常的問題及應對案：4市場發展很

21、迅速，注冊戶數、活這些數據也是節節攀升，所有統計報表的數字都是向好。但是帶來的挑戰也越來越，這個時期也是最危險的時期：在業務快速發展中，既要保證好已有業務的穩定性，要快速地迭代新功能，還要克服團隊招聘節奏跟不上業務發展的問題。這個階段典型的特征是應個數在 5 到 50 個，QPS 在 10 到 1000。這個時期經常會遇到的問題概括起來就是兩個：穩定性問題和開發效率問題。穩定性的問題：戶數多起來之后，系統的穩定性就顯得較重要，論是戶在某段時間遇到異常報錯增多，還是某個功能點持續性地報錯，再到系統有段時間完全不可，這些都會影響產品在戶中的碑，最后這種完全不可的場景，甚還可能成為微博等社交絡上的輿

22、論熱點。開發效率的問題：隨著戶的增多，相應的需求也越來越多，業務場景也越來越復雜，在這個時候測試可不是內部測試就能覆蓋所有的場景，需要加在測試上的投。雖然功能需求越來越多，但是迭代的速度卻要求越來越快，因為市場中已經出現了競爭者，如果他們抄得快，新功能也上得快，業務有可能會競爭不過，特別是當巨頭親下場的時候，更需要跑得更快，開發節奏要快，測試節奏要快，發版節奏也要快。那么如何去解決這兩個場景的痛點呢，這時候可以要借助微服務治理的能來解決。1.開發測試提效Microservices Governance Technologya.【開發環境隔離】傳統的多套開發環境，需要使多套的物理環境，才能實現多

23、套環境各獨互不擾，但是多套物理環境的隔離的機器成本是很的，基本上不能接受。但通過全鏈路灰度這種邏輯隔離的式實現開發環境隔離，可以在不增加成本的情況下增加多套開發測試環境，助你實現敏捷開發。b.【動化回歸測試】動化回歸測試功能，可以將多個測試例串聯成測試例集，將上條測試的返回值作為下跳測試參，串聯成具體的業務場景并沉淀到動化回歸測試中，在每次的發版之前都跑次動化回歸來驗證功能的正確性，這樣就可以節省測試的成本。更進步，還可以通過流量錄制回放功能，將線上的真實流量錄制下來，并沉淀成動化回歸例集，在測試環境進流量回放，更進步地提升測試 case 的覆蓋率。5c.【服務契約】功能越來越多，迭代越來越快

24、，API 越來越復雜，團隊之間溝通的效率越來越低，API 檔嚴重過期。如果能動成服務契約，可以有效地避免檔腐化造成的開發效率低下的問題。使上三點之后，可以在低成本的條件下持多套開發測試環境，實現動化回歸測試，實現開發節奏和測試節奏的提效。2.安全發布a.【損下線】損下線問題的根本原因是開源的微服務體系沒有確保應提供者節點在停服務前確保已經通知到所有消費者不再調，也法確保在處理完所有請求之后再停應。所以新發版的應，即使業務代碼沒有任何問題，也可能在發布過程影響戶的體驗。b.【損上線】損上線問題出現的原因是因為在某些場景下服務提供者，需要經過段時間才能正常地接收流量的請求并成功返回。同時在 K8s

25、 場景下，還需要和 K8s 中的 readiness 、滾動發布等命周期緊密結合，才能確保應發布過程中能不出現業務報錯。c.【全鏈路灰度】新功能上線之后，可以通過灰度規則控制哪些戶可以使。這樣可以先選擇讓內部戶使，測試新功能的正確性。當內部戶驗證通過后，再漸漸地擴灰度范圍，確保每個功能都經過充分驗證后再全量開放給客戶，屏蔽掉發布新功能的險。且當出現問題時，可以通過修改灰度規則來實現快速回滾，做到新版本發版時乎險。使以上點之后，可以確保新版本的發布不出問題，且可以做到天在流量場景下也輕松發布，在實現天輕松發布之后，天就可以發布多次，提升發布時候的穩定性和發版的效率。3.屏蔽偶發異常導致的險a.【

26、離群實例摘除】對于這些偶發的異常問題，離群摘除功能可以智能判斷應中的服務提供者某個出現了問題，智能地在段時間內屏蔽掉這個服務提供者，保證業務的正常，等這個服務提供者恢復過來之后再進調?？梢栽趹濣c出現偶發異常時，智能屏蔽掉此節點，以免影響業務，等此節點恢復后再繼續提供服務，從屏蔽偶發異常導致的險。據統計數據顯示，有將近 90%的線上故障是由于發版過程中出現的，剩下的 10% 左右的線上Microservices Governance Technology6問題，可能是由于些偶然的原因導致的。如偶然的絡故障、機器 I/O 出現問題、或者是某臺機器負載過等。在解決了發布時候的穩定性問題和偶發異常導

27、致的險后，基本能夠確保線上業務不會出現災難性的問題。在業務快速發展的死存亡期，您需要借助于這些微服務治理能，才能確保業務能夠快穩地增，度過這段死存亡期，成為這個領域的重要玩家。業務成熟期當業務進成熟期之后，業務的開發進了新的階段，這時候，雖然快速發展過程中的問題仍舊存在，但是會因為業務量上來之后，遇到新的問題。低成本創新：雖然發展不像原來那么迅速，但是業務創新探索的訴求仍舊存在，由于業務規模的擴，創新的成本也在增加。這個時候不僅是需要快速開發迭代，更的需求是盡可能的成本進創新探索測試，有時候還需要使上 AB 測試的段進實驗較。容災多活：由于業務規模已經很了，治理中的穩定性的訴求更加強烈，且隨著

28、業務范圍的擴，應也開始在多個地域、多個云產品中進部署。同城容災、異地多活這類需求也開始出現。問題定位：出現任何問題都必須徹查。雖然出現問題時，業務恢復仍舊排查第位，但是業務恢復之后的問題根因定位也是不能少的，因為如果不徹查，難免后續出現同樣的問題。險預案：緊急預案、險預防也變得常重要，需要提前做好業務的保護和降級的埋點演練，在遇到絕多數可預問題可以緊急修復，出現不可控問題時，可以通過預案段執預案，確保整體業務的可控性。從這個典型的案例中，我們可以看到，微服務的成功落地和業務的快速發展，離不開微服務治理的持。在業務發展的不同階段，會遇到不同的微服務問題，需要借助于治理的能，為業務的快穩發展保駕護

29、航。Microservices Governance Technology71.2 微服務治理在云原場景下的挑戰企業上云的四個階段隨著云原時代的到來，越來越多的應在云上，在云上，且隨著越來越多的企業開始上云，云原也是企業落地微服務的最佳伴侶。我們分析了阿云典型客戶的實踐經歷，業務上云通常劃分為 4 個階段：云上部署、云原部署、微服務化、服務治理。Microservices Governance Technology云上部署這階段我們解決的問題，如何把傳統業務，原來是跑在建 IDC 機房的業務，能夠原封不動的遷移到云上。通常云商提供了豐富的計算，存儲，絡等資源可供選擇，以虛擬化技術，神裸屬服務為

30、代表的硬件可以滿企業客戶上云搬遷的豐富需求，這階段關注的焦點是資源，對于業務并任何的改造，只需要從本地原樣搬遷到云上即可。云原部署云原是釋放云計算價值的最短路徑，以容器技術為代表，云原提供了強的調度，彈性等能，極的降低了上云的成本。這階段我們關注的標主要是業務進云原化改造，隨著 Kubernetes 作為容器編排市場的事實標準， 我們需要把業務從原來的的虛擬機部署式改造成容器化式，部署并運在 K8s 之上，最限度享受到云原帶來的技術紅利。這階段核關注標以容器為核。8Microservices Governance Technology微服務化當我們的業務規模逐步擴，傳統單體應很難進步撐業務的發

31、展，業務的迭代速度已經法滿業務的增，此時我們就需要進微服務化的改造，降低業務的耦合度，提升開發迭代的效率，讓開發更加敏捷。這階段我們聚焦以應為核。服務治理當微服務的規模也越來越的時候，如果對微服務不加以規范和整治，很容易出現問題。例如，每個微服務都有獨的團隊來維護，他們之間如果依賴沒有整理清楚，可能會出現架構上循環依賴等問題。從我們的數據觀察來看，當微服務的節點數超過數個的情況下，我們通常就需要引服務治理，通常需要關注的是開發，測試，線上運維，安全等多考慮，這階段我們聚焦以業務為核，核標是進步提開發效率，提線上業務的穩定性。微服務治理在云原下的挑戰隨著企業微服務化進程的逐漸深，微服務的云原化逐

32、步進深區，在這個微服務深化的過程中，我們逐步會臨系列的挑戰，總的，我們將這些挑戰分為三個的層，他們分別是效率，穩定和成本。我們進微服務化，本身的使命是讓業務的迭代更加效，但當我們的微服務數量逐步增多，鏈路越來越，如果不進進步的治理，那么引發的效率問題可能會于微服務架構本身帶來的架構紅利。在上章節中我們提到過在微服務實施的不同階段，遇到的問題也不盡相同。前阿巴巴內部的微服務節點數量是在百萬級別，在這個過程我們也積累的常多的治理經驗。9在效率上臨的挑戰在效率需要追求的標是，在開發，線上運維，SDK 升級等更加效。在開發階段，我們需要考慮的是，業務應上云之后，如何讓本地開發的應，很好的部署云上的業務

33、進聯調？通常我們的微服務不可能在本地完整的部署整套系統，所以本地開發的應只是整個微服務鏈路的部分，這包括我們的流量需要能夠輕松的從云上，引導到本地，便于我們做開發調試，或者我們在本地能夠很便的調云上部署的微服務進聯調。這在微服務上云之后，變的原來在身機房進開發聯調更加困難。在線上運維，我們通常需要頻繁的對微服務進變更，這些變更通常就會引發系列的問題，例如在天峰期做發布，通常都會導致業務流量出現損失，我們的研發員不得不選擇在晚上業務低峰期做變更，這降低了研發員的幸福指數，因為他們不得不臨熬夜加班的困境。如果能在天流量峰期也能進流量損的變更，那么這對于研發員來說將是提升研發效率的事情。微服務框架通

34、常會引服務治理的邏輯，這些邏輯通常會以 SDK 的式被業務代碼所依賴，這些邏輯的變更和升級，都需要每個微服務業務通過修改代碼的式來實現，這樣的變更造成了常的升級成本。以阿巴巴為例，阿內部個中間件 SDK 的升級，如果要在整個集團鋪開，通常需要消耗的時間以年為單位進統計，這也會消耗每個微服務應的研發，測試等龐的資源，效率常低下，如果能夠以侵的式實現中間件 SDK的升級，那么將會是件常效的事情。Microservices Governance Technology進云原體系之后，以 K8s 為主的云原體系強調集群之間的靈活調度型，以 POD 為單位任意的調度資源，在被調度后 POD 的 IP 也將

35、相應的發變化，傳統的服務治理體系，10通常以 IP 為維度進治理策略的配置，例如名單策略等，但是當進云原場景后，這些傳統的治理策略都會臨失效的問題，因為 POD 旦被重新調度，原來的治理策略都將不再使，如何能讓服務治理體系更加適應云原體系，也是我們要臨的挑戰。Microservices Governance Technology在穩定上臨的挑戰穩定于切，在微服務上云之后，業務可是我們必須要解決的問題，因此通常會在同個地域的多個可區內進部署，在多可區部署的情況下，跨可區的延時就是不可忽視的問題，我們需要思考的是業務流量需要能夠盡量在同個可區內進流轉，同時也需要考慮的是如果個可區出現問題，業務流量

36、能夠盡可能快的流轉到正常的可區，這就對我們的微服務框架的路由能提出了挑戰。當然，我們的業務不僅需要在同個地域保證可，也需要考慮個地域出問題的時候，保證業務的可，這時我們就需要考慮業務實現同城雙活，甚是異地多活，這對我們來說也是挑戰。第三，微服務之間的調也需要更加的安全可信，近期層出不窮的安全漏洞，定程度上也反應出當前上云階段在安全便暴露出的問題還是常多，每次安全漏洞出現之后，中間件 SDK的升級也是困擾業務多年的問題；同時，些敏感的數據，即使在數據庫層做了常多的權限管控，由于微服務被授予了數據訪問的較權限，如果微服務的調被惡意攻擊，也可能會造成敏感數據的泄露。微服務之間的調需要更加可靠可信。在

37、成本上臨的挑戰先，在成本，業務上云遇到的最大問題就是如何最低成本的把業務遷移上云，對于個在線業務，如果要進停機遷移，那么遷移的成本會顯得常，對于客戶的體驗也會收到影響，要在不中斷業務的情況下，實現平滑遷移上云，還是有常的挑戰的。其次，當我們在業務臨極速增的流量時，迫切的需要快速的彈性，補充更多的資源以承載業務的峰，當我們進業務低峰的時候，希望能夠縮容量，節省資源，因此云產品提供的快速靈活的彈性機制，是微服務上云之后項急需的能。11HSF 在阿巴巴使更多，承接了內部從單體應到微服務的架構演進，撐了阿歷年雙的平穩運； 2008 年 5 發布第個版本 1.1 后，經歷數年迭代，HSF 從個基礎的RP

38、C 框架逐漸演變成為撐萬億級別調的易于擴展的微服務框架。內部場景中，戶既可以選擇少量配置輕松接微服務體系，獲取性能的穩定服務調。也可以按照身業務需求對 HSF 進擴展，獲取整條鏈路的能增強。Microservices Governance Technology1.3 微服務治理的發展趨勢背景云原時代下，我們看到云原微服務作為核的技術直保持著 20%左右的速增，微服務技術也滲透到各各業。在云原微服務技術逐漸趨于成熟的今天，我們以阿集團微服務發展與阿云微服務產品發展的歷史為鏡再次展望微服務發展的趨勢。阿集團微服務發展歷史服務框架就像鐵路的鐵軌樣，是互通的基礎，只有解決了服務框架的互通，才有可能完成

39、更層的業務互通，所以相同的標準統，合為并共建新代的服務框架是必然趨勢。Dubbo3 是 Dubbo2 與 HSF 融合來，是阿里巴巴集團向內部業務、商業化、開源的唯標準服務框架。Dubbo 和 HSF 在阿集團的實踐Dubbo 則在 2011 年開源后，迅速成為業界受歡迎的微服務框架產品，在國內外均有著泛應。Dubbo 項誕于 2008 年，起初只在個阿內部的系統使；2011 年，阿B2B 決定將整個項開源，僅了年時間就收獲了來不同業的批戶；2014 年，由于內部團隊調整，Dubbo 暫停更新；2017 年 9 ，Dubbo 重啟開源，在 2019 年 5 由Apache 孵化畢業，成為第個由

40、阿巴巴捐獻 Apache 畢業的項。12HSF 統天下對于集團內的需求，穩定和性能是核，因此，當時選型了在電商這種并發場景久經考驗的 HSF 做為新代服務框架核。隨后，HSF 推出了 2.0 的版本，并針對 HSF 之前版本的主要問題進重構改造，降低了維護成本，進步提了穩定性和性能。HSF2.0 解決了通訊協議持不透明，序列化協議持不透明等框架擴展性問題?；?HSF2.0 的 Java 版本，集團內也演進出了 CPP/NodeJs/PHP 等多語的客戶端。由于 HSF 還兼容了 Dubbo 的協議，原有的 Dubbo 戶可以平滑地遷移到新版本上，所以 HSF 推出后很快就在集團全鋪開，部署的

41、 server 數量達到數萬， 基本完成了阿巴巴內部微服務框架的統， 并經歷了多年雙零點流量洪峰的驗證。Pandora 與 HSF 搭檔HSF 的順利落地離不開其豐富的周邊態，服務注冊中、配置中、限流降級、流量調度、功能開關、分布式事務、預案平臺這些都是 HSF 的好伙伴，除了起完成基本的微服務調功能之外，也在多次的雙中進保駕護航。這么多的組件， 他們的 SDK 之間的升級和依賴管理是個很難規避的問題。 如果沒有進很好的管理，就可能出現兩種組件之間的三依賴互相沖突的情況。也有可能出現某些組件需要特定的版本組合才能正確使，這些對于開發者來說，分辨起來是個不的成本。如果某個版本的組件出現危 bug

42、，需要推動全量升級，這些開發、構建、發布的成本，更是難以預估。為了解決這些問題，Pandora 孕育。Pandora 是個輕量級的隔離容器，它來隔離Webapp 和中間件的依賴，也來隔離中間件之間的依賴。Pandora 會在運時通過類隔離的式，將各個中間件之間的三依賴隔離開來，有效地避免了三依賴互相沖突的情況。同時，Pandora 還會在運時導出中間件的類，來替換 SDK 中所引的中間件類，這樣就可以實現運時的中間件版本和開發時的中間件版本分離。 應升級 SDK 只需升級 Pandora 容器即可，只有在版本升級時才需要修改 BOM 和重新打包。三位體戰略下服務框架與服務治理的最終選擇 Dub

43、bo3隨著業務的發展，阿集團也因為同時存在 HSF 與 Dubbo 框架導致的不少問題。原有部或公司的技術棧如何更快地融到現有技術體系是個繞不開的問題。Microservices Governance Technology13個典型的例就是 2019 年加阿巴巴的考拉?？祭爸笔?Dubbo 作為微服務框架，基于 Dubbo 構建了規模的微服務應，遷移的成本，險也。需要集團和考拉的基礎架構部耗費較的時間進遷移前調研、案設計，確?；究珊笤匍_始改動。從分批灰度上線，再到最終全量上線。這種換式的改動不僅需要耗費量，時間跨度也很，會影響到業務的發展和穩定性。同時由于歷史原因，集團內部始終存在著定數

44、量的 Dubbo 戶。為了更好的服務這部分戶，HSF 框架對 Dubbo 進了協議層和 API 層的兼容。但這種兼容僅限于互通，隨著Dubbo 開源社區的多年發展，這種基礎的兼容在容災、性能和可迭代性，都有著較的劣勢，同時很難對 Dubbo 的服務治理體系。在穩定性也存在險，更法享受到集團技術發展和 Dubbo 社區演進的技術紅利。隨著云計算的不斷發展和云原理念的泛傳播，下代微服務也帶來了其他的挑戰和機遇，微服務的發展有著以下趨勢：1.K8s 成為資源調度的事實標準， Service Mesh 從提出到發展今已經逐漸被越來越多戶所接受。屏蔽底層基礎設施成為軟件架構的個核演進標，論是阿巴巴還是其

45、他企業戶，所臨的問題都已經從是否上云變為如何平滑穩定地低成本遷移上云。2.由于上云路徑的多樣以及由現有架構遷移云原架構的過渡態存在，部署應的設施靈活異變，云上的微服務也呈現出多元化的趨勢?？缯Z、跨商、跨環境的調必然會催基于開放標準的統協議和框架，以滿互通需求。3.端上對后臺服務的訪問呈爆炸性的趨勢增，應的規模和整個微服務體系的規模都隨之增。這些趨勢也給 HSF 和 Dubbo 帶來了新的挑戰。 產這些問題的根本原因是閉源的 HSF 法直接于云上戶和外部其他戶，開源產品對閉源產品的挑戰會隨著開源和云的不斷發展愈演愈烈。越早解決這個問題，阿巴巴和外部企業戶的云原遷移成本越低，產的價值也就越。因此，

46、HSF 和 Dubbo 的融合是勢所趨。為了能更好的服務內外戶，也為了兩個框架更好發展，Dubbo3 和以 Dubbo3 為內核適配集團內基礎架構態的 HSF3 應運。Microservices Governance Technology14阿云微服務產品發展歷史我們站在現在開始回顧的時候，驚奇地發現阿云微服務產品的發展歷程跟阿集團微服務發展的歷史也是常的相似，或許跟我們最開始創新的源泉來于阿集團的實踐是分不開的。HSF + Pandora 時代阿云上最早輸出微服務治理的產品是 EDAS，定位于分布式應服務站式解決案，最初主推的微服務案是 HSF + Pandora 的式，直接將阿內部已經經過

47、雙驗證的性能框架在云上輸出，同時還輸出了 HSF 周邊的態組件，如注冊中、配置管理、鏈路跟蹤、限流降級等，在經推出之后，常受正在數字化轉型的企業歡迎，服務了常多的政府服務、事業單位、銀客戶以及新零售轉型的頭部企業，也取得了不錯的成績。隨著業務的深，我們的客戶除了頭部政企、數字化轉型的團隊，也越來越多的互聯客戶開始使我們的產品。微服務框架是基礎組件，部分公司在早期選型或業務發展到定規模的時候都需要確定使某個框架。個穩定效的研框架通常需要較時間的迭代來打磨優化。所以部分公司初期都會傾向于使開源組件。對當時阿云微服務產品，這就帶來了個問題：內部使的是 HSF 框架，云上的戶部分都是使的開源 Dubb

48、o 框架，兩種框架在協議、內部模塊抽象、編程接和功能持上都存在差異?？蛻粼谏显频臅r候，不得不對的業務代碼進改造，開發和遷移成本常。另外，由于代碼不開源，對于許多戶，整個服務框架對于他們來說是個盒的組件，排查問題是個常頭疼的問題，戶會擔穩定性得不到保證，也擔被云商技術綁定。我們發現這并不是個很好的產品化向，調研之后發現客戶多數的微服務框架都會選擇開源的 Dubbo/Spring Cloud，于是阿云也選擇了擁抱開源的式，主推 Dubbo 與 SpringCloud 框架。擁抱開源，侵持 Dubbo 與 Spring Cloud對于微服務框架來說，由于關聯到客戶的業務代碼，要做商業化還是有常的挑戰

49、的。即使是已經在微服務治理能上持了開源的 Spring Cloud 和 Dubbo， 但是戶使起來卻不是Microservices Governance Technology15那么容易。先，遷移成本上來說，希望把降低遷移成本為 0。個已經運起來的微服務業務，都會有建的注冊中，如果要上云還需要把的注冊中遷移到 MSE 注冊中上。這個過程需要戶對代碼做改造才，般來說會采雙注冊的案，通過實現在兩個注冊中同時注冊和訂閱的案，來實現新應可以互相調，做到平滑遷移上云。但是我們發現推動客戶做代碼改造，包括 SDK 的升級是件常難的事情，很多客戶的Dubbo 版本還停留在 4-5 年的版本，不僅需要研發、測

50、試、運維都來關注，還需要排期持，這個動作會耗費量的資源，同時臨許多穩定性的挑戰，光是這步就會阻擋住絕多數的的客戶。為了解決客戶 SDK 升級的問題，我們在想，能不能不要遷移注冊中呢，最好是代碼也不改，部署到云上來，就能完整地使我們的微服務治理能。在調研了多技術實現后，我們開始基于 Java Agent 字節碼增強的技術來開發微服務治理的能，幫助戶不改代碼使云產品，真正做到了遷移和使的成本為 0。同時，由于不修改任何代碼，客戶也可以做到隨時可上可下，沒有綁定，較放的上云產品。對于商業化中微服務框架的選擇，我們選擇的態度直是擁抱開源。并在開源微服務框架的基礎上提供差異化的服務治理能，傳統開源微服務