電子書中涉及的部分服務治理技術和最佳實踐，已經通過OpenSergo對外進行開源，該項目由阿里云、bilibili、字節跳動、ApacheDubbo/dubbogo社區、Nacos社區、SpringCloudAlibaba社區共同維護，相關微服務治理技術已被來自各行各業的數千家企業所采用，特別鳴謝上海三菱電梯、來電科技、Saleforce中國為此書撰寫推薦序，歡迎更多企業加入，共建服務治理開放社區。 阿里云開發者“藏經閣”海量電子手冊免費下載如此龐?的微服務體系必須要通過服務治理進?精細化管控，提升線上業務穩定性。阿?集團了豐富的服務治理能?，涵蓋了開發、測試、線上運維、?可?等多個??。這本技術??書系統化的闡述了服務治理的演進路線以及落地最佳實踐，相信對企業開發者和架構師在采納微阿?巴巴作為國內微服務的先?者，有著豐富的實踐經驗和技術積累，近?年阿?巴巴中間件團隊推?三位—體的技術戰略，把內部業務?持、云產品、開源進?了技術和架構的統—，并開源了—系列優秀的項?，包括ApacheDubbo，ApacheRocketMQ、Nacos、Spring間件團隊在微服務領域的又—?作，詳盡介紹了阿?巴巴針對?規模微服務場景下，進??效治理的?案和思想，推薦?前有計劃或已經完成了微服務改造、對微服務領域技術有興趣的技在微服務架構已經??其道的今天，為什么我們要談微服務治理？就像?斯洛需求模型所述，?類的需求是?理、安全、社交、尊重和?我成就的逐步實現。類似的，企業實施微服務架構這是微服務框架所覆蓋的基本功能。第?階段要解決微服務應?的交付和規?；\維問題，這率急劇下降開始成為開發者主要痛點，因此?催?了分布式鏈路跟蹤和可觀測性技術。正所謂因此微服務治理是微服務演進的第四個必然階段，微服務治理得到重視是恰逢其時。 合了阿??身的微服務實踐，以及中間件上云之后?服務外部企業客戶的第—?案例，我認為本書?論從內容的豐富度，還是經驗的普適性來看，都是國內最有參考價值的—份微服務架構行者，通過多年的阿里巴巴內部演進與支持，以及與大量的阿里云外部客戶的共同努力，沉淀出在業界領先的微服務領域特別是服務治理上的一套方法論以及最佳實踐。這本白皮書，正是微服務治理方法論以及最佳實踐的歸納與總結，可以幫助大家在微服務架構設計與管理上提供同時又巧妙的規避了升級、版本不一致等等維護的代價。如果你正好采用微服務架構來完善自己的應用體系，這個白皮書絕對值能幫助你完善你的架構設計，為你的業務穩定運行提供技術為?的微服務?態，阿?巴巴為此作出了卓越貢獻。在和阿?云和阿?巴巴合作過程中，深深感受到阿?云的技術氛圍和底蘊，通過?侵?的JavaAgent，全?代碼零侵?，提供了?縫切換阿?微服務治理技術?案。阿?云的服務治理的模型，依托阿?云堅實的底座，結合阿?云云上資源，使得我們能夠快速融?阿?云服務治理，形成統—，標準，最佳的微服務治理?案。微服務治理技術，思想，解決?案，最佳實踐都在本書有詳細的闡述，是值得每個技術?來電科技擁有百萬級的物聯網終端，中后臺微服務化后擁有數百個微服務組件，管理這些微服務是個極其復雜的工程。阿里云MSE微服務治理技術幫助來電無侵入地實現了服務預熱、無損上下線、全鏈路灰度等微服務治理能力，大大提升了服務的穩定性。如果你正準備深入微服隨著業務的發展和團隊擴大，微服務架構成為了許多大規模開發團隊的不二選擇。在微服務架構發展的過程中，我們經歷了從傳統分布式微服務框架治理到云原生微服務治理的演變。伴隨著服務數量的增多以及對服務穩定性要求的提高，社區上和公有云上都誕生了許多優秀的微服務治理工具。阿里云中間件團隊針對開發者們在微服務開發中遇到的痛點，結合阿里云生態，在本書講述了云原生下微服務治理架構的設計以及微服務治理的最佳實踐。相信這本白皮書能第三章：微服務治理在云原?場景下的解決?案 -微服務開發不簡單如果采?得當，微服務架構可以帶來?常?的優勢。微服務架構的最?好處是它可以提升開發定義好的通訊接?進?l更好的容錯性：微服務之間可以實現更好的故障隔離，單個服務內的內但是微服務在實施過程中，也很容易遇到—些難點。如果微服務治理得不恰當，反?有可能適得其反，不僅不能享受到微服務架構帶來的好處，反?會因為微服務帶來的系統復雜性，造成1 可能會出現很多不確定的問題，會出現遠程調?不可?或者延遲較?的情l隨著業務的發展，微服務之間的拓撲圖開始變l當功能涉及到多個微服務模塊時，迭代時需要謹慎地-個微服務成功落地的典型案例觀察了阿?云眾多客戶之后，我們總結抽象了—個微服務成功落地的典型案例，敘述了某公司是如何借助于微服務架構的紅利，實現了業務快速增?的。案例詳細說明了在業務發展的不同階段，該公司在微服務實施過程遇到的問題，也描述了如何通過微服務治理來解決這些問題，初創公司在剛起步時，雖然業務量?較?、業務模式?較簡單，但是為了在后續的快速發展中能夠快速迭代，同時公司的?才儲備也滿?微服務開發的條件，于是在初創期就選擇了使?微在技術選型??，如果公司創始員?是技術出身，那么會?較傾向于使???擅?的微服務框這—階段組件也很簡單。簡單的兩三個應?，?戶系統、業務系統23對于—個?產級別的系統來說，在將整套系統部署上線之前，還需要建設監控報警系統。監控報警系統能夠幫助我們實時監控機器和應?的狀態。我們可以配置預設的報警規則，在出現機器資源不?，業務出現異常報錯時這些情況時主動報警，提醒我們盡快處理系統中的?險和異常。保留問題的現場，并幫助我們快速地定位和排查問題也同樣重要，阿?云應?實時監控服但是業務的開發和運營從來都不是—帆?順的，在這個過程中，肯定也會遇到很多問題，我們在活過初創期之后，公司的業務很受?戶和市場的歡迎，注冊的?戶越來越多，?戶使?的時?和功能點也越來越多，?活數越來越?，甚?市場中還出現了其他競爭者開始抄襲公司的業務，一些巨頭還親?下場參與競爭。公司業務發展得?常順利，這也意味著系統進?了快速發 4市場發展很迅速，注冊?戶數、?活這些數據也是節節攀升，所有統計報表的好。但是帶來的挑戰也越來越?，這個時期也是最危險的時期：在業務快速發展中，既要保證穩定性的問題：?戶數多起來之后，系統的穩定性就顯得?較重要，?論是?戶在某段時間遇到異常報錯增多，還是某—個功能點持續性地報錯，再?到系統有—段時間完全都會影響產品在?戶中的?碑，最后這種完全不可?的場景，甚?還可能成為微博等社交?絡開發效率的問題：隨著?戶的增多，相應的需求也越來越多，業務場景也越來越復雜，在這個時候測試可不是內部測試就能覆蓋所有的場景，需要加?在測試上的投?。雖然功能需求越來越多，但是迭代的速度卻要求越來越快，因為市場中已經出現了競爭者，如果他們抄得快，新功能也上得快，業務有可能會競爭不過，特別是當巨頭親?下場的時候，更需要跑得更快，開a.【開發環境隔離】傳統的多套開發環境，需要使?多套的物理環境，才能實現多套環境各?獨?互不?擾，但是多套物理環境的隔離的機器成本是很?的，基本上不?能接受。但通過全鏈路灰度這種邏輯隔離的?式實現開發環境隔離，可以在不增加成本的情況下增加多套開發測b.【?動化回歸測試】?動化回歸測試功能，可以將多個測試?例串聯條測試的返回值作為下—跳測試?參，串聯成具體的業務場景并沉淀到?動化回歸測試中，在每—次的發版之前都跑—次?動化回歸來驗證功能的正確性，這樣就可以??節省測試的??成本。更進—步，還可以通過流量錄制回放功能，將線上的真實流量錄制下來，并沉淀成?動5API?檔嚴重過期。如果能?動?成服務契約，可以有效地避免?檔腐化造成的開發效率低下使?上?三點之后，可以在低成本的條件下?持多套開發測試環境，實現?動化回歸測試，實a.【?損下線】?損下線問題的根本原因是開源的微服務體系沒有確保應?提供者節點在停?服務前確保已經通知到所有消費者不再調???，也?法確保在處理完所有請求之后再停?應讓內部?戶使?，測試新功能的正確性。當內部?戶驗證通過后，再漸漸地擴?灰度范圍，確保每個功能都經過充分驗證后再全量開放給客戶，屏蔽掉發布新功能的?險。?且當出現問題使?以上?點之后，可以確保新版本的發布不出問題，?且可以做到?天在?流量場景下也輕松發布，在實現?天輕松發布之后，—天就可以發布多次，提升發布時候的穩定性和發版的效a.【離群實例摘除】對于這些偶發的異常問題，離群摘除功能可以智能判斷應?中的服務提供者某個出現了問題，智能地在—段時間內屏蔽掉這個服務提供者，保證業務的正常，等這個服務提供者恢復過來之后再進?調??？梢栽趹?節點出現偶發異常時，智能屏蔽掉此節點，以 6某臺機器負載過?等。在解決了發布時候的穩定性問題和偶發異常導致的?險后，基本能夠確在業務快速發展的?死存亡期，您需要借助于這些微服務治理能?，才能確保業務能夠?快?當業務進?成熟期之后，業務的開發進?了新的階段，這時候，雖然快速發展過程中的問題仍低成本創新：雖然發展不像原來那么迅速，但是業務創新探索的訴求仍舊存在，由于業務規模的擴?，創新的成本也在增加。這個時候不僅是需要快速開發迭代，更?的需求是?盡可能?容災多活：由于業務規模已經很?了，治理中的穩定性的訴求更加強烈，?且隨著業務范圍的擴?，應?也開始在多個地域、多個云產品中進?部署。同城容災、異地多活這類需求也開始問題定位：出現任何問題都必須徹查。雖然出現問題時，業務恢復仍舊排查在遇到絕?多數可預?問題可以緊急修復，出現不可控問題時，可以通過預案?段執?預案，從這個典型的案例中，我們可以看到，微服務的成功落地和業務的快速發展，離不開微服務治理的?持。在業務發展的不同階段，會遇到不同的微服務問題，需要借助于治理的能?，7企業上云的四個階段隨著云原?時代的到來，越來越多的應??在云上，?在云上，且隨著越來越多的企業開始上我們分析了阿?云典型客戶的實踐經歷，業務上云通常劃分為4個階段：云上部署、云原?部的遷移到云上。通常云?商提供了豐富的計算，存儲，?絡等資源可供選擇，以虛擬化技術，神?裸?屬服務為代表的硬件可以滿?企業客戶上云搬遷的豐富需求，這—階段關注的焦點是云原?是釋放云計算價值的最短路徑，以容器技術為代表，云原?提供了強?的調度，彈性等能?，極?的降低了上云的成本。這—階段我們關注的?標主要是業務 8當我們的業務規模逐步擴?，傳統單體應?很難進—步?撐業務的發展，業務的迭代速度已經?法滿?業務的增?，此時我們就需要進?微服務化的改造，降低業務的耦合度，提升開發迭每個微服務都有獨?的團隊來維護，他們之間如果依賴沒有整理清楚，可能會出現架構上循環依賴等問題。從我們的數據觀察來看，當微服務的節點數超過數?個的情況下，我們通常就需要引?服務治理，通常需要關注的是開發，測試，線上運維，安全等多??考慮，這—階段我微服務治理在云原?下的挑戰隨著企業微服務化進程的逐漸深?，微服務的云原?化逐步進?深?區，在這個微服務深化的過程中，我們逐步會?臨—系列的挑戰，總的??，我們將這些挑戰分為三個?我們進?微服務化，本身的使命是讓業務的迭代更加?效，但當我們的微服務數量逐步增多，鏈路越來越?，如果不進?進—步的治理，那么引發的效率問題可能會?于微服務架構本身帶來的架構紅利。在上—章節中我們提到過在微服務實施的不同階段，遇到的問題也不盡相同。?前阿?巴巴內部的微服務節點數量是在百萬級別，在這個過程我們也積累的?常多的治理經9云上的業務進?聯調？通常我們的微服務不可能在到本地，便于我們做開發調試，或者我們在本地能夠很?便的調?云上部署的微服務進?聯問題，例如在?天?峰期做發布，通常都會導致業務流量出現損失，我們的研發?員不得不夜加班的困境。如果能在?天?流量?峰期也能進?流量?損的變更，那么這對于研發?員賴，?這些邏輯的變更和升級，都需要每—個微要在整個集團鋪開，通常需要消耗的時間以年為單位進?統計，這??也會消耗每個微服務 通常以IP為維度進?治理策略的配置，例如穩定?于—切，在微服務上云之后，業務?可?是我個地域的多個可?區內進?部署，在多可?區部署的情況下，跨可?區的延時就是不可忽視的問題，我們需要思考的是業務流量需要能夠盡量在同—個可?區內進?流轉，同時也需要考慮的是如果—個可?區出現問題，業務流量能夠盡可能快的流轉到正常的可?區，這就對我們的當然，我們的業務不僅需要在同—個地域?保證保證業務的?可?，這時我們就需要考慮業務實現同城雙活，甚?是異地多活，這對我們來說第三，微服務之間的調?也需要更加的安全可信，近期層出不窮的安全漏洞，—定程度上也反的升級也是困擾業務多年的問題；同時，—些敏感的數據，即使在數據庫層做了?管控，由于微服務被授予了數據訪問的較?權限，如果微服務的調?被惡意攻擊，也可能會造?先，在成本??，業務上云遇到的最大問題就是如何最低成本的把業務遷移上云，對于—個在線業務，如果要進?停機遷移，那么遷移的成本會顯得?常?，對于客戶的體驗也會收到影其次，當我們在業務?臨極速增?的流量時，迫切的需要快速的彈性，補充更多的資源以承載業務的?峰，當我們進?業務低峰的時候，?希望能夠縮?容量，節省資源，因此云產品提供務技術也滲透到各?各業。在云原?微服務技術逐漸趨于成熟的今天，我們以阿?集團微服務阿?集團微服務發展歷史服務框架就像鐵路的鐵軌—樣，是互通的基礎，只有解決了服務框架的互通，才有可能完成更可以選擇少量配置輕松接?微服務體系，獲取?性能的穩定服務調?。也可以按照?身業務需 HSF-統天下對于集團內的需求??，穩定和性能是核?，因此，當時選型了在電商這種?并發場景的管理，就可能出現兩種組件之間的三?依賴互相沖突的情況。也有可能出現某些組件需要特定的版本組合才能正確使?，這些對于開發者來說，分辨起來是—個不?的成為了解決這些問題，Pandora孕育??。Pandora是—個輕量級的隔離容器，它?來隔離Webapp和中間件的依賴，也?來隔離中間件之間的依賴。Pandora會在運?時通過類隔離的?式，將各個中間件之間的三?依賴隔離開來，有效地避免了三?依賴互相沖突的情況。同三位-體戰略下服務框架與服務治理的最終選擇Dubbo3基礎架構部?耗費較?的時間進?遷移前調研、?案設計，確?；究?后再開始改動。從分戶，HSF框架對Dubbo進?了協議層和API層的兼容。但這種兼容僅限于互通，隨著隨著云計算的不斷發展和云原?理念的?泛傳播，下—代微服務也接受。屏蔽底層基礎設施成為軟件架構的—個核?演進?標，?論是阿?巴巴還是其他企業?2.由于上云路徑的多樣以及由現有架構遷移?云原?架構的過渡態存在，部署應?的設施靈活異變，云上的微服務也呈現出多元化的趨勢。跨語?、跨?商、跨環境的調?必然會催?基于3.端上對后臺服務的訪問呈爆炸性的趨勢增?，應?的規模和整個微服務體系的規模都隨之增直接?于??云上?戶和外部其他?戶，?開源產品對閉源產品的挑戰會隨著開源和云的不斷發展愈演愈烈。越早解決這個問題，阿?巴巴和外部企業?戶的云原?遷移成本越低，產?的 阿?云微服務產品發展歷史我們站在現在開始回顧的時候，驚奇地發現阿?云微服務產品的發展歷程跟阿?集團微服務發阿?云上最早輸出微服務治理的產品是EDAS，定位于分布式流降級等，在—經推出之后，?常受正在數字化轉型的企業歡迎，服務了?常多的政府服務、隨著業務的深?，我們的客戶除了頭部政企、數字化轉型的團隊，也越來越多的互聯?客戶開始使?我們的產品。微服務框架是基礎組件，?部分公司在早期選型或業務發展到—定規模的時候都需要確定使?某—個框架。?—個穩定?效的?研框架通常需要較?時間的迭代來打磨上都存在差異?？蛻粼谏显频臅r候，不得不對??的業務代碼進?改造，開發和遷移成本?常?。另外，由于代碼不開源，對于許多?戶??，整個服務框架件，排查問題是—個?常頭疼的問題，?戶會擔?穩定性得不到保證，也擔?被云?商技術綁我們發現這并不是—個很好的產品化?向，調研之后發現客戶?多數的微服務框架都會選擇開源的Dubbo/SpringCloud，于是阿?云也選擇了擁抱開源的?式，主推Dubbo與Spring對于微服務框架來說，由于關聯到客戶的業務代碼，要做商業化還是有?常?的挑戰的。即使建的注冊中?，如果要上云還需要把??的注冊中?戶對代碼做改造才?，—般來說會采?雙注冊的?案，通過實現在兩個注冊中?同時注冊和但是我們發現推動客戶做代碼改造，包括SDK的升級是—件?常難的事情，很多客戶的這個動作會耗費?量的??資源，同時?臨許多穩定性的挑戰，光是這—步就會阻擋住絕?多?改，部署到云上來，就能完整地使?我們的微服務治理能?。在調研了多?技術實現后，我對于商業化中微服務框架的選擇，我們選擇的態度—直是擁抱開源。并在開源微服務框架的基主要包括微服務發布過程中的?損上下線，標簽路由，服務鑒權，離群實例摘除，全鏈路灰度 云原?下微服務治理發展趨勢我們親身經歷了阿?集團的微服務的發展與選擇，也參與了阿?云微服務產品的發展。我們觀后端服務BaaS化務，典型的如數據庫，緩存，消息隊列等等，過去我們搭建—個微服務體系通常使?開源軟件??搭建這些后端的依賴，但是維護這些后端組件需要?量的??資源和成本，—旦出問題?險?常?。隨著業務的云原?上云，我們發現越來越多的云廠商通過云服務的形式，提供這些后端依賴的托管服務，免去了業務開發??運維這些軟件的煩惱。由此使得企業越來越聚焦在??的業務應?上，?更少的去關注底層的中間件依賴。過去我們從數據庫開始，再到消息隊列，緩存，?乎所有的云廠商都提供了托管的服務供選擇，然?隨著微服務化進—步深?，我們認為微服務的注冊中?，配置中?，微服務?關，服務治理中?，分布式事務等也逐步由云?的依賴，讓基礎設施的迭代可以脫離業務發展獨?進?。同時，微服務各個語?之間通常會有不同的框架，這些跨語?的微服務框架將形成統—的服務治理控制?，進—步降低客戶選擇第三個趨勢是企業上云部署形態不再會選擇單—云廠商，?論是從避免?商鎖定，還是從穩定性來講都會考慮跨多個云?商提供服務，因此云廠商提供的服務會趨向于標準化，否則企業很有可能選擇開源?建來避免?商的鎖定；同時，企業上云也?—蹴?就，通常?量的業務仍部態，對業務進?統—的管理，也是擺在企業?前的難題。未來的云服務，應該是可以提供跨多總結隨著云計算的迅速發展，微服務將?處不在。云原?微服務治理的標準也在逐漸成型。相信在形態混合云化，會逐漸成為云原?下微服務治理的標準，也相信標準的形成會進—步助?云原 我們基于應?開發、測試、運維的不同階段，對服務治理的概念做—個區分，分為開發態、測開發態服務治理l服務契約：業務開服能夠清晰的了解應用定義了哪些接口、每個接口的參數、l服務調試：在微服務開發和運行時快速地對某個接口進行調試，而不需要經過l端云互聯：本地開發的微服務可以快速的訪問云上的服務，云上的服務也能調用到本測試態服務治理l服務壓測：微服務上線前快速發起壓測，迅速了解微服務的容量是否偏離基線，l流量回放：將錄制好的流量重新運行，驗證當前的業務運行結果是否和錄制好的請運?態服務治理?損下線：確保應用在發布、停止、擴容時，所有請求都不會被影響，?損上線：應用剛啟動時可能會存在一些資源未初始化完成、未預熱完畢的?絲雀發布：滿足特定流量特征的請求才會進入微服務的灰度節點，通l全鏈路灰度：一個迭代的多個應用同時發布，希望經過灰度的上游流量只能達l配置鑒權：某些配置?較敏感，不希望任何微服務都有權限訪問，控制只 l降級：在資源有限的情況下，針對某些不重l熔斷：客戶端訪問后端服務不可用的情況下，返回固定異常或預定義的結果，第?章：微服務治理技術原理介紹正如第—章所說，服務治理從趨勢上來說正在向?侵?，和業務解阿?巴巴服務治理技術演進路線第-階段：?研微服務業務迭代的速度，由五彩?項?開始了微服務化的改造，在這個改造過程中，也逐步誕?了服 隨著中間件接?數量的增加，業務升級成本不斷攀升，從2013年起誕?了代號“Pandora”率的問題。同—個組件，業務和中間件的可能依賴不同的版本，最常?的例如?志，序列化組件等等，如果?家共享—個版本則會出現中間件的升級影響到業務，或者出現不兼容的情況。件—次性打包交付給業務?升級。這—點和Maven引?的bom的思路類似，但是相?是因為即使是Pandora的?式，也需要業務修改代碼，升級，驗證，發布，這些并?業務真正關?，業務更希望專注于?身業務的發展。通常借助雙?—?促這樣的機會，才有可能完成獨立SDK模式阿里巴巴通過五彩石項目開始了微服務化的改造，逐步誕生了服務框架，消息隊列，數據庫分在這個階段，由于基礎設施團隊對部署、開發模式比較熟悉，業務接入的模式也比較單一。業優先、標簽路由能力；消息隊列提供了高可用能力；數據庫分庫分表提供了讀寫分離、動態分Fat-SDK模式 力，讓各個中間件組件能夠有自己獨立依賴且互不沖中間件作為提供?，苦于業務?不能及時升級中JavaAgent技術OneJavaAgent 所以阿?云內部將各個中間件的JavaAgent作為插件(plugin)，組裝成—個統—的Java云原?場景下如何?動注?JavaAgent容器鏡像。這對于運維來說是及其繁瑣的事情。因此我們需要—種?式，能夠將?動注?配置Webhook，然后根據Pod或者Namespace中的Labels，來判斷是否要掛載Java Linkerd，成為業界?個ServiceMesh項?，同年Lyft發布Envoy，成為第?個l1.5版本開始將原有的多個組件整合為—個單體結構istiod；同時廢棄了被詬病已久的出自：https://istio.io/latest/about/service-mesh/Istiod作為控制?的統—組件，負責對接服務注冊發現、路由規則管理、證書管理等能?，出自：https://istio.io/latest/docs/concepts/security/ 流量劫持能?iptables是Linux內核中的防?墻軟件netfilter的管理?具，位于?戶空間，同時也是成，PilotAgent會?來獲取Envoy的啟動配置，然后創建—個Envoy的進程，同時會對出自：https://jimmysong.io/blog/sidecar-injection-iptables-and-traffic-routing/基于eBPF流量劫持能?次，造成?量的性能損失，這對—些性能要流量路由過程Pod內的應?程序容器建?連接，可以通過訪問15000的admin接?查看業務Pod的基于EnvoyFilter的服務治理 ?執?不同任務的HTTP連接管理?系統，可以查看每個Envoy的ConfigDump看到第三章：微服務治理在云原?場絕?多數的軟件應??產安全事故發?在應?上下線發布階段，盡管通過遵守業界約定俗成的可灰度、可觀測和可滾回的安全?產三板斧，可以最?限度的規避發布過程中由于應??身代因此，本節將圍繞發布過程中如何解決流量有損問題實現應?發布過程中的?損上下線效果相?損上下線背景據統計，應?的事故?多發?在應?上下線過程中，有時是應?本身代碼問題導致。但有時我們也會發現盡管代碼本身沒有問題，但在應?上下線發布過程中仍然會出現短時間的服務調?發布經歷的同學或多或少可能有—定了解，?且?家發現該類問題—般在流量?峰時刻尤為明顯，半夜流量少的時候就?較少見，于是很多?便選擇半夜三更進?應?l服務?法及時下線：服務消費者感知注冊中?服務列表存在延時，導致應?特定實 l注冊太早：服務存在異步資源加載問題，當服務的滾動發布—般關聯的就緒檢查機制，是通過檢查應志來觸發下—批次的實例發布，但在微服務應?中只?損下線由于微服務應用自身調用特點，在高并發下，服務提供端應用實例的直接下線，會導致服務消費端應用實例無法實時感知下游實例的實時狀態因而出現繼續將請求轉發到已下線的實例從而圖1SpringCloud應?消費者?法及時感知提供者服務下線已下線的A實例導致出現流量有損?；谏鲜霰尘埃瑯I界提出了相應的?損下線（也針對該類問題，業界一般的解決方式是通過將應用更新流程劃分為手工摘流量、停應用、更新重啟三個步驟。由人工操作實現客戶端避免調用已下線實例，這種方式簡單而有效，但是限制較多：不僅需要借助流控能力來實現實時摘流量，還需要在停應用前人工判斷來保證在途請求已經處理完畢。這種需要人工介入的方式運維復雜度較高，只適用于規模較小的應用，無法解決當前云原生架構下，自動化的彈性伸縮、滾動升級等場景中的實例下線過程中的流量有損問一般注冊中心都提供了主動注銷接口供微服務應用正常關閉時調用，以便下線實例能及時更新其在注冊中心上的狀態。主動注銷在部分基于事件感知注冊中心服務列表的微服務框架比如Dubbo中能及時讓上游服務消費者感知到提供者下線避免后續調用已下線實例。但對于像式實現。盡管下線實例通過注冊中心主動注銷接口更新了其自身在注冊中心上的應用狀態信息但由于上游消費者需要在下一次拉取注冊中心應用列表時才能感知到，因此會出現消費者感知注冊中心實例變化存在延時。在流量較大、并發較高的場景中，當實例下線后，仍無法實現流量無損。既然無法通過注冊中心讓存量消費者實例實時感知下游服務提供者的變化情況，業界圖2?損下線?案無法實時被上游消費者A感知到，從而導致調用已下線實例的問題。在接收到下線命令線前，提供者B對于在等待下線階段內收到的請求，在其返回值中都增加上特殊標記讓服務消費者接收到返回值并識別到相關標志后主動拉取一次注冊中心服務實例從而實時感知B實例最 在并發度不?的場景下，主動通知?法可以解決絕?部分應?下線流量有損問題。但對于?并發?流量應?下線場景，如果主動通知完，可能仍然存在—些在途請求需要待下線應?處理完才能下線否則這些流量就?法正常被響應。為解決該類在途請求問題，可通過給待下線應?在圖3?適應等待機制如上圖3所示，?適應等待機制是通過待下線應?損上線圖4應?啟動資源初始化與正常運?過程中耗時情況對?把新應?發布到線上直接處理?流量極易出現?量請求響應慢，資源阻塞，應?實例宕機的現業界針對上述應??損上線場景提出如下包括延遲注冊、?流量服務預熱以及就緒檢查等—系圖5?損上線整體?案對于初始化過程需要異步加載資源的復雜應?啟動過程，由于注冊通常與應?初始化過程同步進?，從?出現應?還未完全初始化就已經被注冊到注冊中?供外部消費者調?，此時直接調 ?由于資源未加載完成可能會導致請求報錯。通過設置延遲注冊，可讓應?在充分初始化后再在線上發布場景下，很多時候剛啟動的冷系統直接處理?量請求，可能由于系統內部資源初始化不徹底從?出現?量請求超時、阻塞、報錯甚?導致剛發布應?宕機等線上發布事故出現。為了避免該類問題業界針對不同框架類型以及應??身特點設計了不同的應對舉措，?如針對預熱?法通過在服務消費端根據各個服務提供者實例的啟動時間計算權重，結合負載均衡算法控制剛啟動應?流量隨啟動時間逐漸遞增到正常?平的這樣—個過程幫助剛啟動運?進?預圖6應??流量預熱過程QPS曲線圖7應??流量預熱過程原理圖StartTime通過元數據的形式注冊到注冊中?中，服務消費端在注冊中?訂閱相關服務實例列表，調?過程中根據WarmupTime、StartTime計算個實例所分批的調?權重。剛啟動StartTime距離調?時刻差值較?的實例權重下，從?實現對剛啟動應?分配更少流量實現對 圖8應??流量預熱權重計算者應?Pod?時間運?期間出現意外后能及時恢復，提供了探針技術來動態檢測應?的運?情死鎖（應?程序在運?，但是?法繼續執?后?的步驟）。在這樣的情況下重啟容器有助于讓測器，就可以控制容器在啟動成功后再進?存活性和就緒檢查，確保這些存活、就緒探測器不 https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/但在微服務應?中只有當應?完成了服務注冊才可對外提供服務調?。因此某些情況下會出現針對這樣—類微服務應?的發布態與應?運?態?法對?的問題導致的應?上線事故，當前業的?法，通過字節碼技術植?應?服務注冊邏輯前后，然后在應?中開啟—個探測應?服務是否完成注冊的端?供Kubernetes的就緒探針進?應?就緒態探測進?綁定?戶的發布態與運參考資料什么是全鏈路灰度?先，我們先看—下在單體架構中，如何對應?中某個服務模塊進?新版本發布。如下圖，應服務級別發布問題變成了應?級別的發布問題，我們需要對應?的新版本?不是服務來實施有?前，業界已經有?常成熟的服務發布?案，例如藍綠發布和灰度發布。藍綠發布需要對服務的新版本進?冗余部署，—般新版本的機器規格和數量與舊版本保持—致，相當于該服務有兩套完全相同的部署環境，只不過此時只有舊版本在對外提供服務，新版本作為熱備。當服務進?版本升級時，我們只需將流量全部切換到新版本即可，舊版本作為熱備。我們的例?使?藍 在藍綠發布中，由于存在流量整體切換，所以需要按照原服務占?的機器規模為新版本克套環境，相當于要求原來1倍的機器資源。灰度發布的核?思想是根據請求內容或者請求流量是—種循序漸進的發布?式。我們的例?使?灰度發布的示意圖如下，基于內容或?例的流量分流。相?藍綠發布，灰度發布在機器資源成本以及流量控制能?上更勝—籌，但缺點就是發在分布式微服務架構中，應?中被拆分出來的?服務都是獨?部署、運?和迭代的。單個服務新版本上線時，我們再也不需要對應?整體進?發版，只需關注每個微服務?身的發布流程即為了驗證服務Cart的新版本，流量在整個調?鏈路上能夠通過某種?式有選擇的路由到Cart此外，使?這些治理策略時可以結合上?介紹的藍綠發布和灰度發布?案來實施真正的服務級 但在真實業務場景中，業務的微服務規模和數量遠超我們的例?，其中—條請求鏈路可能經過數?個微服務，新功能發布時也可能會涉及到多個微服務同時變更，并且業務的服務之間依賴錯綜復雜，頻繁的服務發布、以及服務多版本并?開發導致流量治理規則?益膨脹，給整個系對于以上的問題，開發者結合實際業務場景和?產實踐經驗，提出了?種端到端的灰度發布?案，即全鏈路灰度。全鏈路灰度治理策略主要專注于整個調?鏈，它不關?鏈路上經過具體哪些微服務，流量控制視?從服務轉移?請求鏈路上，僅需要少量的治理規則即可構建出從?關到整個后端服務的多個流量隔離環境，有效保證了多個親密關系的服務順利安全發布以及服務全鏈路灰度的解決?案如何在實際業務場景中去快速落地全鏈路灰度呢？?前，主要有兩種解決思路，基于物理環境這種?案需要為要灰度的服務搭建—套?絡隔離、資源獨?的環境，在其中部署服務的灰度版本。由于與正式環境隔離，正式環境中的其他服務?法訪問到需要灰度的服務，所以需要在灰度環境中冗余部署這些線上服務，以便整個調?鏈路正常進?流量轉發。此外，注冊中?等—這個?案—般?于企業的測試、預發開發環境的搭建，對于線上灰度發布引流的場景來說其靈活性不夠。況且，微服務多版本的存在在微服務架構中是家常便飯，需要為這些業務場景采?過?，成本和代價遠超收益；如果應?數?很?，就兩三個應?，這個?式還是很?便的，可 另—種?案是構建邏輯上的環境隔離，我們只需部署服務的灰度版本，流量在調?鏈路上流轉時，由流經的?關、各個中間件以及各個微服務來識別灰度流量，并動態轉發?對應服務的灰上圖可以很好展示這種方案的效果，我們用不同的顏色來表示不同版本的灰度流量，可以看出無論是微服務網關還是微服務本身都需要識別流量，根據治理規則做出動態決策。當服務版本發生變化時，這個調用鏈路的轉發也會實時改變。相比于利用機器搭建的灰度環境，這種方案不僅可以節省大量的機器成本和運維人力，而且可以幫助開發者實時快速的對線上流量進行精標簽路由通過對服務下所有節點按照標簽名和標簽值不同進?分組，使得訂閱該服務節點信息的服務消費端可以按需訪問該服務的某個分組，即所有節點的—個?集。服務消費端可以使?服務提供者節點上的任何標簽信息，根據所選標簽的實際含義，消費端可以將標簽路由應?到那么如何給服務節點添加不同的標簽呢？在如今?熱的云原?技術推動下，?多數業務都在積在使?KubernetesService作為服務發現的業務系統中，服務提供者通過向ApiServer提交Service資源完成服務暴露，服務消費端監聽與該Service資源下關聯的Endpoint資源，從 在使?Nacos作為服務發現的業務系統中，—般是需要業務根據其使?的微的環境變量來完成標簽的添加操作。?如我們希望為節點添加版本灰度標，那么為業務容器添請求鏈路上各個組件如何識別出不同的灰度流量？答案就是流量染?，為請求流量添加不同灰度標識來?便區分。我們可以在請求的源頭上對流量進?染?，前端在發起請求時根據?戶信息或者平臺信息的不同對流量進?打標。如果前端?法做到，我們也可以在微服務?關上對匹息中不含有灰度標識，需要?動為其染?，接下來流量就可以在后續的流轉過程中優先訪問服還有—個很重要的問題是如何保證灰度標識能夠在鏈路中—直傳遞下去呢？如果在請求源頭染?，那么請求經過?關時，?關作為代理會將請求?關的路由策略中實施請求內容修改策略。接著，請求流量會從??服務開始調?下—個微服務，會根據業務代碼邏輯形成新的調?請求，那么我們如何將灰度標識添加到這個新的調?請從單體架構演進到分布式微服務架構，服務之間調?從同—個線程中?法調?變為從本地進程的服務調?遠端進程中服務，并且遠端服務可能以多副本形式部署，以?于—條請求流經的節分布式鏈路追蹤技術對?型分布式系統中請求調?鏈路進?詳細記錄，核?思想就是通過—個全局唯—的traceid和每—條的spanid來記錄請求鏈路所經過的節點以及請求耗時，其中借助于分布式鏈路追蹤思想，我們也可以傳遞—些?定義信息，?如灰度標識。業界常?的分 流量標識鏈路傳遞以及流量?動染?。此外，需要引?—個中?化的流量治理平臺，?便各個企業?產級服務治理產品，您不需要修改任何—?業務代碼，即可擁有不限于全鏈路灰度的治MSE微服務治理全鏈路灰度SpringCloud流量可根據請求的cookie、header、param參數或隨機百分?引?流量，2)灰度流量攜帶灰度標往下游傳遞，形成灰度專屬環境流量泳道，?灰度環境應?會默認選擇未打標的應?屬于基線穩定版本的應?，即穩定的線上環境。當我們將發布對應的灰度版本代 RPC流量的全鏈路灰度?案尾量可觀測等核?能?，以更經濟的?式、更?效的路徑幫助我們的系統在云上快速構建起完整 訴我們系統出問題了，那么可觀測就可以告訴我們系統哪里出問題了，什么原因導致的問題。lMetrics:是—種聚合的度量數值，提供量化的系統內/外部各個維度的指標，—般包括lLogging:應?運?過程中產?的事件或者程序執?過程中產?的—些?志，可以給我們提我們可以將指標、追蹤和日志數據的進行進一步關聯、分析，推導出當前微服務系統所處的狀云原生下微服務應用可觀測的挑戰 到以容器為核心的容器化云原生部署；為了更加敏捷，阿里云開始以應用為核心的微服務化。如今，當微服務發展到一定應用規模，阿里云開始圍繞業務核心從云服務器ECS到Kubernetes，微服隨著多種治理能力深入，可觀測要求高，服務框架復雜度增加，技術門檻提升，數據本身復雜 當前一些監測工具無法實現服務框架服務發現層面的問題診斷，導致遺留了許多服務調用問題難以排查，單看監控使得客戶根本無從下手。因此，我們希望通過提供以下方面服務發現監控2、微服務應用連接的是哪個注冊中心，服務發現鏈路調用示例圖，大塊內容有Provider、微服務可觀測增強包含哪些??當前的一些監控工具無法實現服務框架服務發現層面的問題診斷，因此遺留許多服務調用的問題難以排查，單看監控會客戶根本無從下手的窘境。因此我們希望通過提供以下方面服務發現監控診斷能力幫助客戶及時排查服務發現領域出現問題導致的應用運行異常：2、微服務應?連接的是哪個注冊中?，服務發現鏈路調?示例圖，?塊內容有Provider、 過于簡單與粗粒度，?法實現服務框架層?的問題診斷，因此遺留許多服務調?的問題難以排查，單看監控客戶根本?從下?。因此我們希望通過增加以下?個維度的監控幫助?戶及時了c、使??研路由能?后性能下降（性能診斷）等我們希望應用啟動過程中，從Springbean加載、鏈接池連接的監測、微服務的服務注冊、微服務場景下可觀測的探索與實踐 通過將整個流程串聯，實時觀察到每個點的耗時，可觀測視圖把問題剖析出來。上圖是容器啟動分析功能。左邊是服務啟動，系統將啟動過程中的每一塊時間拆分出來，從而清晰看微服務引擎提供了無損上線的能力。控制臺動態配置，實時無損上下線可觀測視圖，完整解決方案無需改一行代碼。在微服務啟動的全流程進行各種方案的保護與治理：預建連接階段通過提前異步創建連接保證不會阻塞在連接建立的過程中；服務注冊發現階段通過并行注冊與訂閱能力進一步提升應用的啟動速度；在小流量預熱階段通過調整客戶端的負載均衡能力保證新起 配置是否配錯地方，是否生效，是否被覆蓋。微服務場景下配置分散且冗余，我們提供應用運 總結微服務可觀測增強方案站在傳統的可觀測性方案之上我們進一步從微服務的視角出發，擴展傳從前端、應用至底層機器，應用實時監控服務ARMS實時監測應用服務的每次運行、每個慢背景介紹問題項本地靜態配置問題描述采?本地靜態配置，導致運?時?法動態修改配置格式不統—散亂，難以管理，有的?XML格式，有的?properties，有的??產事故容易將??產配置帶到?產環境，引發事故配置修改困難部署多臺節點時，修改配置費時費?，周期?缺少安全審計和版本控制能??法追溯責任?，?法得知修改內容，?法確定修改時間，?法及時回滾針對上述問題，應?配置中?應運??，但市場上存在的配置中?產品側重點及適?場景各不或是減少日志打印帶來的性能消耗。功能開關提供了在應用運行時動態修改日志級別的功能， 必要的信息，我們在使用日志框架時會設置默認的日志級別。而程序在線上運行時，我們需要單擊操作列的全局推送或單機推送，按照<loggerName,logg{{}可按不同場景批量更新組合配置項，所謂組合配置項指具有一組相互關聯業務語義的配置項，'商品優惠配置'在不同場景下優惠對象、優惠折扣及價格等各不相同，將'商品優惠配置'涉及的以開關方式控制代碼執行邏輯，用于新功能快速驗證，在出現問題時可及時回退。相比復雜的如下圖所示，當執行邏輯觸發時訪問對應的開關配置查看配置是否打開，從而決定是否執行新 應用配置解決方案介紹下文首先通過對比現有產品，分析競品優勢與劣勢，進而引出本應用配置解決方案核心設計要選取較為有代表性且具有?定市場規模的產品進?對?，分析產品的適?場景，為?戶產品選產品配置時效性Switch社區版動態配置，需??實現可靠推送Togglz動態配置，可靠推送AppConfig時?效Apollo動態配置，實時?效AHAS功能開關（MSE應?配置）動態配置，開箱即?，可靠推送，實時?效配置覆蓋能?僅?持單機推送持久化多節點覆蓋多節點覆蓋快速覆蓋上千服務實例配置灰度能?不?持?持?持?持?持簡單配置?持可以當做bool類型的開關?持?持?持復雜類型的業務配置?持不?持?成本?不?持?動校驗，保證類型安全可觀測能??控制臺，不?持?持弱法直接觀測?持?屏化觀測能?，控制臺可觀測各接?節點的實時?效值和分布情況 產品微服務?態?持Switch社區版?直接?持Togglz?開箱即??持AppConfig?直接?持Apollo?持SpringCloud微服務家族配置項AHAS功能開關（MSE應?配置）開箱即?的SpringCloud@Value及@ConfigurationProperties配置動態管理能?開箱即?的運維管控能?不?持不?持不?持?持?持，如動態?志級別調整代碼侵?性有侵?有侵?有侵?JavaAgent?式?侵?，但功能存在問題JavaAgent?式???戶?需在業務層?對接收到的配置進?類型及格式的校驗，校驗?作由平臺承擔，應?僅需 背景介紹微服務的穩定性—直是開發者?常關注的話題。隨著業務從單體架構向分布式架構演進以及部署?式的變化，服務之間的依賴關系變得越來越復雜，業務系統也?臨著巨?的?可?挑戰。影響微服務可?性的因素有?常多，?這些不穩定的場景可能會導致嚴重后果。我們從微服務服務，假設某個?付服務出現異常，調??常慢，?調?端?沒有有效地進?預防與處理，熔斷降級、熱點防護、系統?適應保護等多個維度來幫助保障服務的穩定性，覆蓋微服務、云域有著?泛的應?，在互聯??融、在線教育、游戲、直播?業和其他?型政央企?業也有著微服務流量防護?段如雙?—零點的場景）。然?我們系統的容量總是有限的，如果突然?來的流量超過了系統的系統崩潰。因此，我們需要針對這種突發的流量來進?限制，在盡可能處理請求的同時來保障服務不被打垮，這就是流量控制。流量控制的場景是?常通?的，像脈沖流量類的場景都是適 這時候通常根據服務提供?的服務能?進?流量控制，或針對特定的服務調??進?限制。我單機流控兜底，更好地發揮流量防護的效果。集群流控既可以?撐數?萬QPS?流量控制，如，?付的時候，可能需要遠程調?銀聯提供的API；查詢某個商品的價格，可能需要進?數據庫查詢。然?，這個被依賴服務的穩定性是不能保證的。如果依賴的服務出現了不穩定的情況，請求的響應時間變?，那么調?服務的?法的響應時間也會變?，線程會產?堆積，最終現代微服務架構都是分布式的，由?常多的服務組成。不同服務之間相互調?，組成?鏈路。以上的問題在鏈路調?中會產?放?的效果。復雜鏈路上的某—環不穩定，就可能會）： 的時候暫時切斷服務的調?，等待—段時間再進?漸進式恢復嘗試?！??防?給不穩定服務調??例）和基于錯誤（錯誤?例/錯誤數可以有效地針對各種不穩定注意熔斷器模式—般適?于弱依賴調?，即熔斷后不影響業務主流程，?并發控制對于弱依賴流量是隨機的，不可預測的。為了防?被?流量打垮，我們通常會對核?接?配置限流規則，有了以上的流量防護場景，是不是就萬事?憂了呢？其實不是的，很多時候我們?法事先就準確評估某個接?的準確容量，甚??法預知核?接?的流量特征（如是否有脈沖情況這時處理異常。這個時候我們其實需要做的是快速?損，先通過—些?動化的兜底防護?段，將瀕 控策略，讓系統的??流量和系統的負載達到—個平衡，讓系統盡可能跑在最?吞吐量的同時保證系統整體的穩定性。系統?適應過載保護可以作為整個服務的—個兜底防護策略，保障服流量漏?防護原則流量漏?原則進??可?流量防護。在流量鏈路的每—層，我們都需要進?針對性的流量防護與容錯?段，來保障服務的穩定性；同時，我們要盡可能地將流量防護進?前?可?防護流程則配置預警與告警規則，這樣在臨近閾值/觸 總結通過流控、熔斷降級、系統?適應過載保護、熱點防護等—系列的微服務流量防護?段，我們可以從微服務?關??，到微服務，再到中間件依賴，這樣全鏈路全?位地為微服務集群提供隨著云原?時代的到來，越來越多的應??在云上，?在云上，且隨著越來越多的企業開始上云，云原?也是企業落地微服務的最佳伴侶。但云上應?易測性受到了很?的挑戰，如何提?上圖是—個典型的企業微服務應?架構圖，為了考慮安全性，云上應?通常部署在云上虛擬局 云原?時代下微服務開發測試以API為測試對象，進?開發?測，功能回歸，性能測試，線上巡檢等測試活動，完成?質量試想—下，研發同學提交代碼并部署，可以使?測試?具，驗證服務邏輯正確性；可以使?壓測?具，驗證服務性能指標；驗證通過后，開始進?冒煙測試，可以使??動化回歸?具，編回歸通過后，提交測試驗收，測試只需要驗證新功能，新功能驗證通過后，即可提交發布。發布后，進?線上環境驗證，需要回歸歷史功能主流程，可以使??動化回歸?具，編寫主流程回歸?例，新功能??驗證；主流程回歸通過且新功能驗證通過，代表發布完成；研發同學，試想—下，企業為了安全隔離，研發環境、測試環境、預發環境、?產環境部署在不同的專有?員明明只想要—個簡單的測試?具，卻因為上云之后，要解決復雜的云上?絡拓撲，遠遠沒有結束，為了能夠在辦公?使?該測試?具，還需要保證該測試?具能夠被辦公?訪問，此時??臨著?絡安全的考驗。云原?時代，我們希望有—個能夠開箱即?且安全可靠的?案，能 業界存在很多API測試?具，相對優秀的?具，例如ApiFox，Postman能就需要?檔，甚?是??相傳，微服務治理已經可視化應?的夠真實地模擬后端服務，?持系統聯調，及?動化測試的落地。壓測管理，可以直接將?動化測試?例—鍵轉化為壓測?例，?戶?需關?壓測機的準提供研發測試效率，加速軟件交付。結合上述3點，測試同學只需負責?例編寫+測試驗收， 微服務敏捷開發不簡單微服務給?家帶來了敏捷開發的特性，基于敏捷開發的帶來的便利，讓我們可以在同—個時間這還有個邏輯沒理清楚呢，剛改完代碼準備測?發，你這?測試聯調我就不能動環境了，我這以上這些問題顯然會影響項?的進度，?常容易造成項?延期。對于此刻的開發?哥哥?為什么精準地控制流量如此重要？舉個最簡單的微服務架構圖來說明，這?假設應?的調?鏈 如何準確地讓請求在feature環境內流轉呢？最簡單的辦法是每個迭代/Feature的都享有—套獨?的完整環境，這套獨?的環境包含了整個微服務應?集所有的應?，包含注冊中?和接因為我們的開發、聯調、測試是需要確保端到端的全流程都是OK的，那這?就還會涉及到域名/SLB/?關/注冊中?這些資源，這些資源—般?較固定，不會需要進??的修改，但是在那么，有沒有?個?較優雅地?式，既能享受到微服務架構帶來的敏捷開發的便利，?不會給?常開發環境的搭建帶來很?的成本呢？基于MSE標簽路由功能使?開發環境隔離?案排除了物理環境隔離的?式之后，我們很?然地去想到，邏輯隔離。簡單地說，表?上看起來有很多套環境，每個環境都有—套完整的微服務應?。但是這些環境內的有些應?節點不是只屬于某—個環境的，是被多個環境共享的，這樣就能減少很多機器的成本。理想中的邏輯隔離我們稱之這唯—的—套完整的環境為基線環境?；€環境包含了所有微修改的應?。這樣維護n套feature環境的成本，就變成了加法，?不是原來的乘法，由 從開源的?度來看，實現邏輯隔離有個?較通?的?式。服務提供者將環境標相關的信息注冊到注冊中??，于是消費者從注冊中?中獲取的服務提供者列表就包含了環境相關的信息。消費者在路由的過程中，對請求的內容進?計算，選擇出與之對應的?標環境，最后再與服務提2.邏輯隔離的過程中，會存在某個應?不存在feature環境的情況，如何在請求被降級到背景介紹相?于傳統的單體應?，使?微服務系統架構雖然能帶來如各微服務之間可獨?開發、運?以及部署等優點。但如何對—個微服務系統中的眾多微服務進?注冊與管理是微服務系統設計過程中的核?內容之—。當前主流的微服務架構中，主要通過設計—個叫作注冊中?的組件來提供對系統中所有服務進?狀態注冊與發現。注冊中?本質上是—個數據庫，其需要實時存儲系統中所有服務的有關狀態以及對應的實例列表信息，由于應?在分布式系統中，其還需要提供—定容錯、?可?等相關能?。下圖是微服務之間通過服務注冊中?來提供服務注冊與發現能圖1基于注冊中?的微服務系統調?如上圖所示，在微服務系統中，所有的微服務實例啟動時都會根據配置信息將服務有關的如服務名稱，服務地址以及端?號等信息發送到系統的注冊中?保存，注冊中?后續過程中也會實時通過?跳等機制探測服務實例的健康程度并及時更新服務狀態。服務注冊后，調??通過服務標識到注冊中?中獲取對應服務的可?實例列表。最后再根據特定的客戶端負載均衡機制從 Master/Slave架構，利?原??播（ZookeeperAtomicBroadcast，ZAB）協議來進?所有節點??—致，數據寫?集群任意—個節點后，再由該節點向集群內其他節點進?復制實Nacos所具備的核?功能外，其還提供了微服務配置中?的相關能?。Nacos集群架構也屬于?所有節點都將存儲集群內所有服務元數據，因此都可以提供數據讀取服務，但每個節點只負責集群架構ZooKeeperMaster/SlaveEureka?Master/SlaveConsulMaster/SlaveNacos?Master/Slave?致性協議~雪崩保護?有?有協議訪問SpringCloud集成?持?持?持?持Dubbo集成?持不?持不?持?持種注冊中?可供?戶選擇。但因為各種注冊中?架構以及形態各異應?的場景不—，不管系統在設計之初采?什么注冊中?解決?案，隨著系統業務的發展演進，或多或少都可能遭遇原有注冊中?難以繼續滿?當前系統對注冊中?服務能?的要求，以下是—些常?的注冊中?遷移1.早期注冊中?技術?案有缺陷，例如注冊中心的可用性要求強于一致性，因此早先配合穩定性得不到保障的等諸多原因近年來促使—?批中?企業放棄了?建注冊中?想法，轉?采注冊中??案介紹要想完成微服務應?遷移上云，注冊中?遷移上云是其中的關鍵。?前業界主流的注冊中?遷 然后逐個將應?中的?建注冊中?配置修改成云上注冊中?配置，最后通過對應?進?重新發布以實現注冊中?的遷移上云。該種?式特點簡單，但所帶來的劣勢是?作量?、涉及?員較?停機遷移是相對于停機遷移的—種?案，其在注冊中?遷移過程中不要求應??即停機修改代碼，通過切流遷移、?建注冊注冊中?與云上注冊中?數據實時同步或者雙注冊雙訂閱的?切流遷移作為非停機遷移中較為容易實現的一種方式，其主要通過開發一套新的應用，在應用中使用新注冊中心，然后通過SLB和域名配置來進行線上切流。該方案雖然圖2NacosSync注冊中?遷移原理圖 2.添加完注冊中?后，需要增加—個同步任務來添加需要同步的服務(對于Dubbo來說就是數據庫連接串相關信息，然后將需要同步的服務—個個輸?到控制臺，才能實現注冊中?同步?字節碼技術動態修改應?代碼，在應?中動態加?新注冊中?依賴包和配置信息，使其在僅需要—次重啟就能實現對?建注冊中?和新注冊中?的雙注冊以及雙訂閱，該?案典型代表是圖4雙注冊雙訂閱實現注冊中?遷移上云2.將系統中下次需要進?發布升級的應?中的?建注冊中?地址改成新注冊中?地址，然后發布上線。盡管新發布的應?不會注冊或者訂閱?注冊中?，但因為其他服務在新注冊中?都有由上述?案介紹內容可知，基于雙注冊雙訂閱的?停機注冊中?遷移?案具有遷移過程便捷、 參考資料概述免線上故障，在不可避免發?故障情況下，希望能夠快速修復，減少線上影響，基于此提出了監控的作?—句話概括就是：發現應?中的問題，并將問題及時告警給技術?員進?處理。監控類型可以分為系統問題的監控與業務問題的監控，系統問題：常?的軟硬件相關問題，?如定業務場景下定義的問題，?如商品?優惠券，權益超發問題等，需要根據業務特征來定制監 豐富性能指標與診斷能?。從業務視?衡量應?性能和穩定性的新?式，對業務的關鍵交易進?全鏈路的監控。業務監控通過追蹤并采集應?程序中的業務信息，實時展現業務級的指標，對于監控的要求有以下三點。實時：要求對問題的發現和預警是實時的，縮短問題產?和發現的時延；準確：要求監控和預警是準確的，包括對監控問題的定義，對預警閥值，預警等級，當監控發現有問題的時候，就需要通過不同等級的告警將問題及時告警給技術?員進?處理。5分鐘定位故障 線程耗時分析?持顯示該應?的所有線程和查看線程的堆棧信息，幫助我們快速定位耗時較??法執?分析?持抓取?法的某—次執?的耗時、?參、返回值等信息和鉆?，幫助您快速定 對象查看器?于查看—些單例對象當前的狀態，?于排查應?狀態異常問題，例如應?配置、實時看板?于查看系統中?到的關鍵組件的實時狀態，例如查看數據庫連接池的使?情況、JVM監控可以直觀展示指定時間段內的多項內存指標，雖然圖表能體現出內存使?量過?的情 在微服務架構中，當服務提供者的應?的某些實例出現異常，?服務消費者?法感知時會影響服務的正常調?，并影響消費者的服務性能甚?可?性。離群實例摘除功能會檢測應?實例的當應?遇到業務?峰期，發現下游的服務提供者遇到性能瓶頸，甚?即將影響業務時。我們可以對部分的服務消費者進?服務降級操作，讓不重要的業務?不進?真實地調?，直接返回?提升整體服務的穩定性。我們把這個過程叫做：服務降級。當應?依賴的下游服務出現不可?的情況，導致業務流量損失。您可以通過配置服務降級能?，當下游服務出現異常時，服務做到相應的效果；?離群實例摘除能?是會主動探測上游節點的存活情況，在這條鏈路上整體），接?名（Interface）為服務名的微服務，如果觸發到這個服務的降級，下次將不再調?這個節數據保護等能?，保障故障場景下的業務快速恢復，助?企業的容災穩定性建設。多活，顧名思義就是分布在多個站點同時對外提供服務。與傳統的災備的最主要區別就是多活?的所有站點同時在對外提供服務，不僅解決了容災本身問題，還提升了業務連續性，并且實現了容量的務可靈活進??險可控的技術演進，例如基礎設施升級、新技術驗證等，甚?可以驅動在商 基于故障應急?式演練，那么在真正遇到線上故障的時候我們才可以更加從容地?對故障。我們希望新—代的云原?微服務能更多地具備系統?愈能?，微服務架構內部可以?動感知外部者服務連不上注冊中?，那么想要連接它的節點可能會因為?法獲取服務地址?對整個系統出本?從—個真實的案例說起，某客戶在阿?云上使?K8s集群部署了許多??的微服務，由于3.這個缺陷版本實際上是已知問題，阿?云在5?份推送了nacos-client1.4.1 最終導致故障的原因是服務?法調?下游，可?性降低，業務受損。下圖示意的是客戶端缺陷回顧整個案例，每—環每個?險看起來發?概率都很?，但是—旦發?服務發現?可?是微服務體系中很重要的—環，當然也是我們時常忽略的點。在阿?內部的故?向失敗的設計情況，經常會出現服務批量閃斷的情況，但這種情況其實不是業務服務的不可?，如果我們的微服務可以識別到這是—種異常情況（批量閃斷或地址變空時應該采取—種保守的策略，站在微服務?度上考慮，我們如何可以切段以上的問題胸脯說，不會發?以上的問題嗎？?向失敗的設計原則告訴我們，如果注冊中?掛掉了，或者我們的服務連不上注冊中?了，我們需要有—個?式保證我們的服務正常調?，線上的業務持服務發現過程中的?可?原理解析?向失敗的設計告訴我們，服務并不能完全相信注冊中?的通知的地址，當注冊中?的推送地 ?跳續約是注冊中?感知實例可?性的基本途徑。但是在特定情況下，?跳存續并不能完全等此時服務并不能完全相信注冊中?的通知的地址，推送的地址中，可能存在—些服務質量低下的服務提供者，因此客戶端需要??根據調?的結果來判斷服務地址的可?性與提供服務質量尾沒有任何系統是百分百沒有問題的，?險是?處不在的，盡管有很多發?概率很?很?，卻都服務發現的?可?是我們時常容易忽視的點，但是它?是?常關鍵的點，—旦我們的系統出現??積服務發現的問題，并且由于微服務依賴的復雜度，導致相關的問題也很難快速恢復。為了避免對整個系統出現災難性的打擊，我們需要對服務發現進??向失敗的設計與演練，才能 為什么需要微服務安全隨著微服務的深?，微服務的安全問題?益成為—個企業關注的重點，微服務所依賴的基礎框架，操作系統內核，如果出現安全漏洞，隨時可能成為—個深?炸彈，對業務系統造成災難性未做任何限制，使得攻擊者可以通過JNDI注?實現遠程加載惡意類到應?中，從?造成程代碼執?漏洞，攻擊者在攻破配置中?后，可通過上傳惡意的script規則等來觸發我們對于數據庫通常都會做嚴格的權限控制，但是由于我們的微服務對數據庫是擁有完全的訪問權限的，所以即使數據庫層?做了?常嚴格的權限控制，—旦微服務層?突破了，也會對數據庫造成災難性的破壞，例如—個?客，假設具備了微服務的訪問權限，可能會發?拖庫等嚴我們對于—些重要的配置，通常會放在統—的配置數據庫的訪問?戶名和密碼，然后通常的配置中?的配置，?家是可以隨意訪問的，如果讓?權訪問改數據庫的?戶拿到了這些敏感數據，則他也可能會獲取到數據庫中的敏感數據。因此微服務安全解決?案/掃描、流量訪問控制、數據泄露檢測等場景，但??層防護也有—定的局限性，??層防護完 全基于流量特征進?檢測，容易產??量?效報警或因擔?誤報規則不敢做太嚴格，這給安全運維會帶來—些負擔，某?戶在在線?檔中上傳—段SQL語句，容易產?誤報；再如，利?再者，基于流量特征的防護只能看到流量內容，即?戶的原始請求，并不能感知應?最終會怎看到應?的上下?，理解應?最終執?了什么動作和命令，不管原始請求怎樣變形，最終應?為不匹配，就可以檢測到異常。對于—些加密?等?段，本質上也是對輸?內容做變形以繞過針對Java微服務應?，基于字節碼增強的?案，l從訪問?式上，可以通過??名單的?式來進?配置。例如，可以配置只允許 背景介紹—個企業內部所開發的微服務有可能都是基于同—個微服務框架完成的，對于這樣的架構，我們稱之為是同構微服務體系；當然也有可能—個企業內的微服務是基于多種不同的微服務框架建?的，這樣的架構我們稱之為是異構的微服務體系。多種不同類型微服務框架的共存在?型企業內還是?較普遍的，形成這種現象的原因有很多，?如：可能是歷史遺留、難以改造的系統；也可能是企業正在做技術棧遷移；?或者是企業內不同業務部?為了滿?各?的特殊需求如何透明地實現異構微服務體系之間的服務發現和服務調?？如果我們什么都不做，那么每個微服務體系就只能感知到??所在體系內的微服務的狀態，流量也只能在各?的體系內封閉流