微服務(wù)治理技術(shù)白皮書

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