摘要：
以淘寶為例，剖析微服務(wù)應(yīng)用故障定位系統(tǒng)實(shí)現(xiàn)原理！
當(dāng)下最流行的設(shè)計(jì)架構(gòu)便是微服務(wù)架構(gòu)，越來(lái)越多的企業(yè)將老的服務(wù)拆分成微服務(wù)模式、在新的業(yè)務(wù)中采用微服務(wù)架構(gòu)的設(shè)計(jì)理念進(jìn)行技術(shù)架構(gòu)設(shè)計(jì)。 其中實(shí)踐的最好的莫過(guò)于阿里了，早期淘寶的架構(gòu)是一個(gè)單體式架構(gòu)，即Linux操作系統(tǒng)+apache服務(wù)器+mysql數(shù)據(jù)庫(kù)+PHP開發(fā)的程序，所有的功能如用戶注冊(cè)與管理、商品管理、訂單管理全都集中在一個(gè)程序包里，業(yè)務(wù)越擴(kuò)展越大，這個(gè)程序包也變得越來(lái)越大，最終長(zhǎng)成了巨無(wú)霸應(yīng)用，難以承受業(yè)務(wù)的繼續(xù)增長(zhǎng)，技術(shù)團(tuán)隊(duì)也難以進(jìn)行維護(hù)。
不過(guò)辦法總比困難多，在千百個(gè)日夜輪回的摸索與實(shí)踐后，終于找到了合適的解決方案，即進(jìn)行重構(gòu)，將原來(lái)的巨無(wú)霸應(yīng)用進(jìn)行業(yè)務(wù)抽象，拆分成獨(dú)立的子服務(wù)，由不同的團(tuán)隊(duì)進(jìn)行開發(fā)與維護(hù)。
以淘寶的體量來(lái)看，該應(yīng)用足以拆分上千個(gè)子業(yè)務(wù)，下圖是2012年淘寶的整個(gè)服務(wù)調(diào)用拓?fù)鋱D，如果到2020年，那么業(yè)務(wù)必定會(huì)更加的復(fù)雜。
不只是淘寶會(huì)有這么復(fù)雜的微服務(wù)鏈路，任何一個(gè)企業(yè)，只要采用微服務(wù)架構(gòu)的模式進(jìn)行技術(shù)架構(gòu)設(shè)計(jì)，勢(shì)必都會(huì)產(chǎn)生復(fù)雜的鏈路調(diào)用，也勢(shì)必都會(huì)面臨著著四個(gè)問(wèn)題：
1）定位故障難。當(dāng)客服向你反饋用戶無(wú)法進(jìn)行下單時(shí)，很難去排查故障原因。表面上只是一個(gè)簡(jiǎn)單的下單操作，背后卻是由幾十個(gè)微服務(wù)所構(gòu)成的，而且是由不同的業(yè)務(wù)團(tuán)隊(duì)進(jìn)行開發(fā)，出現(xiàn)問(wèn)題了需要牽扯十幾個(gè)部門一起排查，定位故障及根本原因太難了。
2）規(guī)劃容量難。對(duì)于服務(wù)平臺(tái)來(lái)說(shuō)，隔三差五的搞個(gè)活動(dòng)、做個(gè)促銷啥的再正常不過(guò)了，一般搞大活動(dòng)之前都會(huì)對(duì)業(yè)務(wù)進(jìn)行壓測(cè)，制定本次活動(dòng)的機(jī)器資源安排，然而測(cè)試環(huán)境與生產(chǎn)環(huán)境情況并不完全一樣，每個(gè)服務(wù)的參與程度、重要性都是不一樣的，規(guī)劃合適的容量太難了。
3）梳理鏈路難。在當(dāng)下，互聯(lián)網(wǎng)企業(yè)的人員流動(dòng)是非常正常的事情，往往一個(gè)系統(tǒng)的從開發(fā)到完成經(jīng)歷了多個(gè)人的手，只有從頭到尾全參與的人才知道系統(tǒng)的技術(shù)架構(gòu)，核心人員流動(dòng)后對(duì)于系統(tǒng)的架構(gòu)梳理、性能優(yōu)化就變得非常難了。一個(gè)剛?cè)肼毜男氯送ū容^久的時(shí)間才能梳理清楚業(yè)務(wù)，才能在業(yè)務(wù)開發(fā)的時(shí)候處理得當(dāng)，不影響上下游業(yè)務(wù)。
4）浪費(fèi)資源多。由定位故障難產(chǎn)生的人力成本、規(guī)劃容量難產(chǎn)生的機(jī)器資源成本、梳理鏈路難產(chǎn)生的人力成本導(dǎo)致了企業(yè)資源的浪費(fèi)。
這些都是實(shí)行微服務(wù)架構(gòu)帶來(lái)的問(wèn)題，那微服務(wù)架構(gòu)問(wèn)題這么多？難道是要讓我們不用它了嗎？
其實(shí)不然，有了問(wèn)題就必然會(huì)有解決方案。一套完整的微服務(wù)解決方案也必然包含故障定位部分，那么業(yè)內(nèi)是如何來(lái)實(shí)現(xiàn)微服務(wù)的故障定位呢？
目前業(yè)內(nèi)的解決方案一般包含三個(gè)模塊，即數(shù)據(jù)采集、數(shù)據(jù)分析、數(shù)據(jù)呈現(xiàn)。
數(shù)據(jù)采集是在應(yīng)用的每個(gè)服務(wù)上安裝探針，當(dāng)服務(wù)的進(jìn)程啟動(dòng)時(shí)，該探針也會(huì)啟動(dòng)，采集服務(wù)運(yùn)行中的數(shù)據(jù)。
數(shù)據(jù)分析是通過(guò)收集的數(shù)據(jù)獲取鏈路調(diào)用關(guān)系、程序執(zhí)行情況。
數(shù)據(jù)呈現(xiàn)即在前端頁(yè)面呈現(xiàn)鏈路拓?fù)?、服?wù)執(zhí)行情況。研發(fā)人員通過(guò)前臺(tái)就可知道整個(gè)服務(wù)鏈路情況、程序運(yùn)行情況，快速定位故障根因，完美解決了微服務(wù)架構(gòu)的四大問(wèn)題！
目前用的最多的應(yīng)用基本是java語(yǔ)言開發(fā)的，因此我們以java應(yīng)用來(lái)進(jìn)行講解整個(gè)監(jiān)控系統(tǒng)的實(shí)現(xiàn)。
我們知道java程序都是在JVM中運(yùn)行的，實(shí)質(zhì)上是將java代碼編譯成的class文件，jvm做的第一件事情便是通過(guò)java.lang.ClassLoader去加載類（比如A.class），此時(shí)探針agent會(huì)截取A.class類嵌入監(jiān)控代碼生成A’.class類，之后所有的用戶請(qǐng)求都會(huì)在A’.class類里執(zhí)行，而我們的監(jiān)控代碼把這些都完完全全的記錄下來(lái)了，并且定時(shí)發(fā)給了后臺(tái)。
探針采集了數(shù)據(jù)后需要后臺(tái)分析，我們先看一個(gè)真實(shí)每天都在上演的業(yè)務(wù)場(chǎng)景，用戶在頁(yè)面發(fā)起“添加購(gòu)物車”、“從購(gòu)物車刪除商品”、“從購(gòu)物車進(jìn)入商品結(jié)算”等等，其實(shí)整個(gè)系統(tǒng)運(yùn)行的每一秒都在發(fā)生著N個(gè)用戶請(qǐng)求，每個(gè)請(qǐng)求的鏈路調(diào)用請(qǐng)求不完全一致，對(duì)于添加購(gòu)物車服務(wù)來(lái)說(shuō)：購(gòu)物車服務(wù)B調(diào)用用戶服務(wù)C、C調(diào)用商品服務(wù)D；對(duì)于從購(gòu)物車刪除商品來(lái)說(shuō)：購(gòu)物車服務(wù)B調(diào)用商品服務(wù)D、商品服務(wù)D調(diào)用商品庫(kù)存服務(wù)E；對(duì)從購(gòu)物車進(jìn)入商品結(jié)算來(lái)說(shuō)，購(gòu)物車服務(wù)B調(diào)用結(jié)算服務(wù)E、支付服務(wù)F….就這短短的一秒鐘，產(chǎn)生了B->C->D、B->D->E、B->E->F….的服務(wù)鏈路，如果其中的某次調(diào)用C->D出了問(wèn)題，那么B系統(tǒng)的研發(fā)人員完全不知道問(wèn)題出現(xiàn)在哪里了。這個(gè)時(shí)候我們要引入兩個(gè)專業(yè)的名詞spanid、traceID。
對(duì)于故障問(wèn)題的定位，通過(guò)traceID就可以進(jìn)行跟蹤。用戶的請(qǐng)求一發(fā)起，我們就給它打上了traceID的標(biāo)簽，隨著這個(gè)請(qǐng)求繼續(xù)的往后面發(fā)生調(diào)用，traceID就繼續(xù)跟著到了下游系統(tǒng)中，一直到請(qǐng)求的調(diào)用執(zhí)行完成，而所有的執(zhí)行都會(huì)記錄在日志中。當(dāng)某次調(diào)用發(fā)生錯(cuò)誤時(shí)，我們只要獲取到這個(gè)traceID，在整個(gè)日志中進(jìn)行搜索，就可以知道它卡在哪里了，找到了問(wèn)題的根本原因。
對(duì)于調(diào)用鏈路的梳理，通過(guò)spanID就可以進(jìn)行還原。當(dāng)整個(gè)用戶請(qǐng)求開始發(fā)生時(shí)，我們把第一次鏈路的調(diào)用賦值為0，每深入一次就疊加一次，比如B->C->D中，B->C是0.1、C->D是0.1.1;每進(jìn)行一次同深度的調(diào)用再自加一次，比如B->D->E中，B->C是0.2、C->D是0.2.1。后臺(tái)系統(tǒng)通過(guò)上萬(wàn)筆的調(diào)用鏈路分析處理，最終會(huì)給到一個(gè)鏈路調(diào)用拓?fù)鋱D
因?yàn)楸O(jiān)控代碼在代碼的執(zhí)行都進(jìn)行了埋點(diǎn)，所以通過(guò)代碼開始和代碼結(jié)束的時(shí)間戳對(duì)比就能獲取到整個(gè)代碼執(zhí)行的時(shí)間和次數(shù)，進(jìn)而獲取到用戶請(qǐng)求的執(zhí)行時(shí)間和執(zhí)行次數(shù)，再進(jìn)而獲取到服務(wù)的執(zhí)行時(shí)間和執(zhí)行次數(shù)，再再獲取到整個(gè)應(yīng)用的執(zhí)行時(shí)間和執(zhí)行次數(shù)，后臺(tái)把數(shù)據(jù)處理好了之后傳遞給到前端，就可以呈現(xiàn)給到用戶整個(gè)微服務(wù)應(yīng)用的執(zhí)行情況了，程序員哥哥們?cè)僖膊挥脫?dān)心微服務(wù)應(yīng)用的故障問(wèn)題找不到，天天996了。
只談微服務(wù)架構(gòu)的設(shè)計(jì)，而不談其出現(xiàn)的問(wèn)題與解決方案便是耍流氓。
在微服務(wù)架構(gòu)時(shí)代，對(duì)于整個(gè)系統(tǒng)的監(jiān)控、調(diào)用鏈路的追蹤、服務(wù)的熔斷限流等機(jī)制都是必不可少的。
工欲善其事，必先利其器。隨著云計(jì)算、5G、人工智能等的普及應(yīng)用，容器技術(shù)、Devops的廣泛應(yīng)用，微服務(wù)必定是會(huì)大放異彩，而其背后的助力無(wú)疑是整個(gè)監(jiān)控系統(tǒng)～
京公網(wǎng)安備 11010802020714號(hào)
京ICP備2020047077號(hào)-2
手機(jī)端官網(wǎng)
