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

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