本發(fā)明涉及一種分布式系統(tǒng)的跟蹤處理方法，尤其是涉及一種分布式服務(wù)跟蹤實(shí)現(xiàn)方法。
背景技術(shù)：
：：如今互聯(lián)網(wǎng)服務(wù)通常都是用復(fù)雜的、大規(guī)模分布式集群來實(shí)現(xiàn)的，互聯(lián)網(wǎng)應(yīng)用構(gòu)建在不同的軟件模塊集上。這些軟件模塊，有可能是由不同的團(tuán)隊(duì)開發(fā)、也有可能使用不同的編程語言來實(shí)現(xiàn)、還有可能分別部署在不同的服務(wù)器上，橫跨多個不同的數(shù)據(jù)中心。因此，就需要有一些可以幫助理解系統(tǒng)行為、用于分析系統(tǒng)性能問題的工具。比如在搜索系統(tǒng)中，用戶的一個請求在系統(tǒng)中會經(jīng)過多個子系統(tǒng)的處理，而且這些處理是發(fā)生在不同機(jī)器甚至是不同集群上的，當(dāng)請求處理發(fā)生異常時，需要快速發(fā)現(xiàn)問題，并準(zhǔn)確定位到是哪個環(huán)節(jié)出了問題，這是非常重要的。為了解決這樣的問題，谷歌開發(fā)了分布式跟蹤系統(tǒng)Dapper并發(fā)布了一篇論文《Dapper,aLarge-ScaleDistributedSystemsTracingInfrastructure》(《Dapper，大型分布式系統(tǒng)跟蹤系統(tǒng)的基礎(chǔ)設(shè)施》)來闡述其核心理論。目前可查的分布式跟蹤系統(tǒng)的實(shí)現(xiàn)，其基本理論都源于谷歌的這篇論文。但是Dapper只是為解決請求調(diào)用這一問題提出了理論模型，并沒有提供具體的實(shí)現(xiàn)。本發(fā)明的分布式跟蹤系統(tǒng)是在博采眾家之長的基礎(chǔ)上提供了完整的分布式系統(tǒng)的跟蹤解決方案，更符合現(xiàn)有SOA(面向服務(wù)的體系結(jié)構(gòu))系統(tǒng)架構(gòu)需求?？梢宰龅浇尤胪该?，對業(yè)務(wù)的性能影響微乎其微，實(shí)時跟蹤，同時本發(fā)明的分布式跟蹤系統(tǒng)提供的實(shí)時預(yù)警功能保證在系統(tǒng)出現(xiàn)異常甚至宕機(jī)的情況下可以及時通知預(yù)警，保證系統(tǒng)的穩(wěn)定性和高可用性。技術(shù)實(shí)現(xiàn)要素：本發(fā)明提供了一種分布式服務(wù)跟蹤實(shí)現(xiàn)方法，解決了分布式系統(tǒng)中進(jìn)程調(diào)用過程中產(chǎn)生問題時的查詢跟蹤問題，其技術(shù)方案如下所述：一種分布式服務(wù)跟蹤實(shí)現(xiàn)方法，包括日志采樣模塊、日志收集模塊、日志存儲模塊、統(tǒng)計(jì)報(bào)表模塊、前端模塊，所述日志采樣模塊利用攔截器攔截技術(shù)或面向切面編程技術(shù)攔截分布式調(diào)用鏈中的進(jìn)程行為，所述日志收集模塊定期實(shí)時讀取文件，并將有用的日志信息發(fā)送到日志存儲模塊，所述統(tǒng)計(jì)報(bào)表模塊定期進(jìn)行日志統(tǒng)計(jì)，前端模塊提供用戶交互界面；整體架構(gòu)稱為Cicada；對于請求發(fā)起進(jìn)程的設(shè)為客戶端，服務(wù)提供進(jìn)程的設(shè)為服務(wù)端，同一次請求的所有相關(guān)調(diào)用的情況稱作分布式調(diào)用鏈，記為Trace，每個分布式調(diào)用鏈擁有一個全局唯一的ID來標(biāo)識，其中所述服務(wù)端調(diào)用其他進(jìn)程時成為該調(diào)用中的的客戶端，該跨進(jìn)程的一次調(diào)用記為Span；在客戶端的前端請求到達(dá)服務(wù)器時，應(yīng)用容器在執(zhí)行實(shí)際業(yè)務(wù)處理之前，會先執(zhí)行Cicada的埋點(diǎn)邏輯，埋點(diǎn)邏輯為這個前端請求分配一個全局唯一的調(diào)用鏈ID，稱為TraceId，埋點(diǎn)邏輯把TraceId放在一個調(diào)用上下文對象Span里面，而調(diào)用上下文對象會存儲在ThreadLocal里面，ThreadLocal能夠基于線程進(jìn)行數(shù)據(jù)的存儲和讀取，能在同一次請求的多個本地處理方法間傳遞信息。所述Span包括客戶端Span和服務(wù)端Span，一個遠(yuǎn)程調(diào)用對應(yīng)兩個span，多條Span形成樹形結(jié)構(gòu)，組合成一次Trace追蹤記錄，在Span中的標(biāo)注點(diǎn)用于記錄整個Span時間段內(nèi)發(fā)生的事件，用特殊標(biāo)注點(diǎn)記錄用戶自定義事件。所述標(biāo)注點(diǎn)的屬性包括timestamp、type、ip、port，分別表示記錄行為發(fā)生時間、記錄行為類型、IP地址、端口；所述特殊標(biāo)注點(diǎn)的屬性包括timestamp、type、ip、port、key、value，分別表示記錄行為發(fā)生時間、記錄行為類型、IP地址、端口、用戶定義屬性名、用戶定義屬性值；所述Span的屬性包括traceId、Id、parentId、appName、serviceName、methodName、subSpanNum、annotations、binaryAnnotations，分別表示分布式調(diào)用唯一id、Span唯一id、Span父id、應(yīng)用名、類名、方法名、子span數(shù)量、調(diào)用信息、補(bǔ)充信息或異常信息。在調(diào)用上下文時設(shè)置有第二種ID，稱作spanId，用于區(qū)分同一個調(diào)用鏈下的多個網(wǎng)絡(luò)調(diào)用的發(fā)生順序和嵌套層次關(guān)系；對于前端收到請求，生成的spanId固定都是1，當(dāng)這個前端執(zhí)行業(yè)務(wù)處理需要發(fā)起RPC調(diào)用時，RPC調(diào)用客戶端Dubbo會首先從當(dāng)前線程ThreadLocal上面獲取之前設(shè)置的調(diào)用上下文，然后，把spanId遞增一個序號，并使用多級序號來表示spanId；之后，調(diào)用上下文會作為附件隨這次請求一起發(fā)送到遠(yuǎn)程的Dubbo服務(wù)器，遠(yuǎn)程的Dubbo服務(wù)端收到這個請求之后，會從請求附件里取出調(diào)用上下文，并放到當(dāng)前線程ThreadLocal上面；如果服務(wù)A在處理時，需要調(diào)用另一個服務(wù)，則會重復(fù)以上步驟，并將spanId遞增一個序號再傳過去，服務(wù)A的邏輯全部處理完畢之后，Dubbo在返回響應(yīng)對象之前，會把這次調(diào)用情況以及traceId、spanId都打印到它的訪問日志之中，同時，會從ThreadLocal清理掉調(diào)用上下文。當(dāng)服務(wù)發(fā)生時，所述日志采樣模塊攔截分布式系統(tǒng)各組成部分的處理行為，記錄行為日志并將日志通過HttpPost異步發(fā)送到日志收集模塊，將收集好的日志發(fā)送到遠(yuǎn)程服務(wù)器時采用批處理和異步發(fā)送的方法，并增加了連接超時設(shè)置和傳輸超時設(shè)置，將超過一定時長的日志直接扔掉，同時對單位時間內(nèi)抓取的日志量過多的情況進(jìn)行了限流處理。所述日志收集模塊分日志接收子系統(tǒng)和日志匯總子系統(tǒng)，所述日志接收子系統(tǒng)為nginx集群，所述nginx接收到客戶端POST過來的消息數(shù)據(jù)，直接記錄本地文件；所述日志匯總子系統(tǒng)從nginx日志中讀取最新數(shù)據(jù)，記錄讀取進(jìn)度并進(jìn)行數(shù)據(jù)清洗，將異步數(shù)據(jù)存儲到ElasticSearch。所述統(tǒng)計(jì)報(bào)表模塊進(jìn)行定期日志統(tǒng)計(jì)，統(tǒng)計(jì)項(xiàng)包括以下：avgDuration：平均響應(yīng)時間；minDuration：最快響應(yīng)時間；maxDuration：最慢響應(yīng)時間；line95Duration：95％line最大響應(yīng)時間；line999Duration:99.9％line最大響應(yīng)時間；failureRate：請求失敗率；提供統(tǒng)計(jì)結(jié)果以及Trace數(shù)據(jù)訪問的RESTful接口。本發(fā)明能夠透明的傳遞調(diào)用上下文，理解系統(tǒng)行為，理清后端調(diào)用關(guān)系，實(shí)現(xiàn)調(diào)用鏈跟蹤，調(diào)用路徑分析，幫助業(yè)務(wù)人員定位性能瓶頸，排查故障原因等；同時，需要對用戶盡量透明，減少對業(yè)務(wù)代碼的侵入性。附圖說明圖1是本發(fā)明中典型的分布式調(diào)用跟蹤模型圖；圖2是一個瀏覽器請求可能觸發(fā)的系統(tǒng)間調(diào)用以及生成spandId的關(guān)系圖；圖3是本發(fā)明整體架構(gòu)的示意圖；圖4是本發(fā)明系統(tǒng)部署圖。具體實(shí)施方式分布式系統(tǒng)為應(yīng)用帶來高可用、高性能、水平擴(kuò)展等特性，同時也給應(yīng)用部署、排查、監(jiān)控等方面帶來了復(fù)雜性。對單一進(jìn)程的系統(tǒng)來說，涉及到用戶一次請求的所有處理都在同一個進(jìn)程里，請求相關(guān)的所有屬性記錄在本地即可，無需在多個系統(tǒng)之間傳遞，方法調(diào)用之間的先后順序按照事件記錄的時間先后順序即可，處理起來也很容易。而對于分布式系統(tǒng)來說，面臨的問題則要復(fù)雜很多。響應(yīng)一次請求的分布式服務(wù)可能分散在不同的服務(wù)器不同的進(jìn)程里，如何準(zhǔn)確的把這些服務(wù)找出并關(guān)聯(lián)起來是其面臨的首要問題。同時，要準(zhǔn)確的分析出這些服務(wù)發(fā)生的先后關(guān)系，也是一個比較棘手的問題。由于服務(wù)相關(guān)的進(jìn)程分布在不同的服務(wù)器上，而服務(wù)器的時間有可能不一致(比如如后服務(wù)的服務(wù)器時間比較靠前，先服務(wù)的服務(wù)器時間比較靠后)如果采用時間進(jìn)行區(qū)分的話，就可能導(dǎo)致分析錯誤。要解決此問題，必須尋求其他解決途徑。上面兩個問題，主要涉及到記錄信息的數(shù)據(jù)結(jié)構(gòu)問題，在解決了這個問題之后，又面臨著一個新的問題，即信息傳遞問題。前面已經(jīng)提到過本地調(diào)用之間、跨進(jìn)程的調(diào)用之間必然存在一些關(guān)聯(lián)信息，而要讓這些關(guān)聯(lián)信息發(fā)揮作用，必然要在所有調(diào)用之間通過某種方式共享信息。在解決了數(shù)據(jù)結(jié)構(gòu)定義以及調(diào)用信息在系統(tǒng)之間傳遞的問題后，需要考慮服務(wù)信息抓取問題，即如何簡單有效、低侵入甚至無侵入的獲取分布式服務(wù)的處理信息。接著，要考慮系統(tǒng)的擴(kuò)展性，用戶可能想自定義一些需要采集的數(shù)據(jù)，以便跟準(zhǔn)確的監(jiān)控、分析服務(wù)運(yùn)轉(zhuǎn)狀態(tài)。最后，要盡可能的把架構(gòu)做的輕量，越是輕量級的服務(wù)，部署起來越容易，排查問題越簡單，越節(jié)省成本。要實(shí)現(xiàn)分布式跟蹤系統(tǒng)，首先要解決的問題是定義好跟蹤模型，模型的關(guān)鍵又在數(shù)據(jù)結(jié)構(gòu)定義。其核心內(nèi)容如下：Client(客戶端)和Server(服務(wù)端)在分布式系統(tǒng)中，請求發(fā)起進(jìn)程和服務(wù)提供進(jìn)程扮演的角色很像是C/S架構(gòu)(經(jīng)典軟件架構(gòu)模型，C代表Client，S代表Server)中客戶端和服務(wù)端的扮演的角色。作為類比，我們稱請求發(fā)起進(jìn)程為Client，服務(wù)提供進(jìn)程為Server。由于存在多層依賴，所以在一次分布式請求中，可能存在這樣一種情況：一個進(jìn)程在處理過程中，同時扮演Client和Server角色。也就是說一個進(jìn)程可能是上一個Span的服務(wù)端，同時是下一個Span的客戶端，比如在一次請求中進(jìn)程A調(diào)用了進(jìn)程B，進(jìn)程B又調(diào)用了進(jìn)程C。對于進(jìn)程A來說，進(jìn)程B的角色是Server，但是對于進(jìn)程C來說進(jìn)程B是Client。Trace(分布式調(diào)用鏈)一次分布式請求涉及到的所有調(diào)用鏈路。一次請求對應(yīng)一個Trace，一個Trace擁有一個全局唯一的Id來標(biāo)識。Span調(diào)用上下文對象，記錄分布式調(diào)用相關(guān)信息，是追蹤服務(wù)基本結(jié)構(gòu)，表示跨進(jìn)程的一次調(diào)用。一個完整的Span包含兩天Span記錄，一條是客戶端Span，一條是服務(wù)端Span。多條Span形成樹形結(jié)構(gòu)，組合成一次Trace追蹤記錄。Annotation在span中的標(biāo)注點(diǎn)，記錄整個span時間段內(nèi)發(fā)生的事件。BinaryAnnotation可以認(rèn)為是特殊的Annotation，用戶自定義事件。那么，Annotation類型包括下面兩種：1、保留類型CSCLIENT_SEND，客戶端發(fā)起請求CRCLIENT_RECIEVE，客戶端收到響應(yīng)SRSERVER_RECIEVE，服務(wù)端收到請求SSSERVER_SEND，服務(wù)端發(fā)送結(jié)果2、用戶自定義類型Event記錄普通事件Exception記錄異常事件圖1是一個典型的分布式調(diào)用跟蹤模型圖，結(jié)合下圖可以幫助我們理解上面的術(shù)語。重要數(shù)據(jù)結(jié)構(gòu)：類：Annotation重要屬性：類說明：記錄span調(diào)用的部分相關(guān)信息，主要是發(fā)生時間和ip信息。類：BinaryAnnotation重要屬性：類說明：記錄span調(diào)用的異常信息或用戶自定義的信息。類：Span重要屬性：類說明：調(diào)用上下文對象，記錄分布式調(diào)用相關(guān)信息，span信息核心類，一個遠(yuǎn)程調(diào)用對應(yīng)兩個span，一個是客戶端span，一個是服務(wù)端span。本發(fā)明的整體處理流程簡單如下所述：日志采集流程：利用Filter(攔截器)攔截技術(shù)或AOP(面向切面編程)技術(shù)攔截進(jìn)程行為將搜集到的數(shù)據(jù)異步批處理發(fā)送到Tengine(由淘寶網(wǎng)發(fā)起的Web服務(wù)器項(xiàng)目。它在Nginx的基礎(chǔ)上，針對大訪問量網(wǎng)站的需求，添加了很多高級功能和特性)集群。Tengine集群收到數(shù)據(jù)后，將數(shù)據(jù)保寫入本地文件日志處理流程：日志收集后處理進(jìn)程定期實(shí)時讀取文件，過濾掉不符合規(guī)則的或無效的日志信息，然后將有用的日志信息發(fā)送到ElasticSearch(用Java(全球通用開發(fā)語言)開發(fā)的，并作為Apache許可條款下的開放源碼發(fā)布，是當(dāng)前流行的企業(yè)級搜索引擎，可以存放數(shù)據(jù))。日志分析進(jìn)程定期實(shí)時從ElasticSearch中讀取日志信息并進(jìn)行匯總處理，匯總處理結(jié)果存放到Mysql(關(guān)系型數(shù)據(jù)庫管理系統(tǒng)，由瑞典MySQLAB公司開發(fā)，目前屬于Oracle旗下產(chǎn)品。)中方便查詢。同時對于滿足報(bào)警條件的處理，發(fā)送報(bào)警信息。日志展示Dashboard(分布式跟蹤顯示頁面)是用于跟用戶交互的前端頁面。能夠根據(jù)用戶的指示展示不同的統(tǒng)計(jì)結(jié)果。本發(fā)明具體的詳細(xì)處理流程如下所述：同一次請求的所有相關(guān)調(diào)用的情況，在Cicada里稱作調(diào)用鏈。同一個時刻某一臺服務(wù)器并行發(fā)起的網(wǎng)絡(luò)調(diào)用有很多，怎么識別這個調(diào)用是屬于哪個調(diào)用鏈的呢？可以在各個發(fā)起網(wǎng)絡(luò)調(diào)用的中間件上下手。具體流程如下：1)TraceId生成及調(diào)用上下文信息存取在前端請求到達(dá)服務(wù)器時，應(yīng)用容器在執(zhí)行實(shí)際業(yè)務(wù)處理之前，會先執(zhí)行Cicada的埋點(diǎn)邏輯(類似Filter的機(jī)制)，埋點(diǎn)邏輯為這個前端請求分配一個全局唯一的調(diào)用鏈ID。這個ID在Cicada里面被稱為TraceId，埋點(diǎn)邏輯把TraceId放在一個調(diào)用上下文對象Span里面，而調(diào)用上下文對象會存儲在ThreadLocal里面。ThreadLocal技術(shù)非常關(guān)鍵，它可以基于線程進(jìn)行數(shù)據(jù)的存儲和讀取，能在同一次請求的多個本地處理方法間傳遞信息。其中前端請求是指當(dāng)用戶的請求發(fā)送到服務(wù)器，Cicada的處理流程，所以這兒的提到的前端請求也可以寫作用戶的請求。所述應(yīng)用容器是從代碼部署的環(huán)境來區(qū)分的，部署在服務(wù)器環(huán)境下的叫做后段，相應(yīng)的發(fā)布到用戶器材上的程序叫做前端，必入瀏覽器、app之類。2)spanId生成細(xì)節(jié)調(diào)用上下文里還有一個ID非常重要，在Cicada里面被稱作spanId。spanId用于區(qū)分同一個調(diào)用鏈下的多個網(wǎng)絡(luò)調(diào)用的發(fā)生順序和嵌套層次關(guān)系。對于前端收到請求，生成的spanId固定都是1。當(dāng)這個前端執(zhí)行業(yè)務(wù)處理需要發(fā)起RPC調(diào)用時，RPC調(diào)用客戶端Dubbo(分布式服務(wù)框架)會首先從當(dāng)前線程ThreadLocal上面獲取之前Cicada設(shè)置的調(diào)用上下文。然后，把spanId遞增一個序號。在Cicada里使用多級序號來表示spanId，比如前端剛接到請求之后的spanId是1，那么它第一次調(diào)用RPC服務(wù)A時，會把spanId改成1.1。之后，調(diào)用上下文會作為附件隨這次請求一起發(fā)送到遠(yuǎn)程的Dubbo(一款開源的分布式服務(wù)框架)服務(wù)器。Dubbo服務(wù)端收到這個請求之后，會從請求附件里取出調(diào)用上下文，并放到當(dāng)前線程ThreadLocal上面。如果服務(wù)A在處理時，需要調(diào)用另一個服務(wù)，這個時候它會重復(fù)之前提到的操作，唯一的差別就是spanId會先改成1.1.1再傳過去。服務(wù)A的邏輯全部處理完畢之后，Dubbo在返回響應(yīng)對象之前，會把這次調(diào)用情況以及traceId、spanId都打印到它的訪問日志之中，同時，會從ThreadLocal清理掉調(diào)用上下文。spanId生成算法如下：圖2展示了一個瀏覽器請求可能觸發(fā)的系統(tǒng)間調(diào)用以及生成spandId的關(guān)系圖。對于現(xiàn)有的同類產(chǎn)品，往往依賴mq(消息隊(duì)列，如Kafka)、bigtable(大數(shù)據(jù)，如HBase，Cassandra)等重量級解決方案，依賴較多。本發(fā)明的技術(shù)選型更加合理。數(shù)據(jù)采集端使用無狀態(tài)的Http協(xié)議，通過批量上傳的方式POST數(shù)據(jù)到數(shù)據(jù)收集端，保證傳輸效率，將對應(yīng)用的性能影響控制在極低范圍。也就是采用批量+HTTPPOST的方式發(fā)送數(shù)據(jù)，發(fā)送策略是批量發(fā)送，發(fā)送方式是POST方法，后面有對POST方法的解釋。數(shù)據(jù)收集端通過高性能的nginx接收客戶端上傳的數(shù)據(jù)，部署簡單，擴(kuò)展方便。后端存儲采用ElasticSearch，在保證吞吐量的基礎(chǔ)之上，擴(kuò)展了ad-hoc(點(diǎn)對點(diǎn))的查詢能力。自行開發(fā)了彈性計(jì)算框架，對物理資源的浪費(fèi)極低。以上各環(huán)節(jié)都可以隨著部署機(jī)器的增加，吞吐量和計(jì)算量達(dá)到水平擴(kuò)展。本發(fā)明采用的方案需要減少對應(yīng)用程序的影響，cicada客戶端主要涉及到兩個功能：一個是日志收集功能，一個是將收集好的日志發(fā)送到遠(yuǎn)程服務(wù)器的功能。前者通常耗時較少，且沒太大優(yōu)化空間；后者涉及到IO，處理較慢，性能優(yōu)化主要針對后者。最終方案采用批處理+異步發(fā)送。那么，本發(fā)明采用下列措施增加日志吞吐量：一、批處理；二、用高性能、低延遲的消息處理框架Disruptor替換BlockingQueue(一種阻塞隊(duì)列)作為線程間傳遞消息的框架，提升消息處理效率；對于日志傳送過程中由于第三方原因(日志收集服務(wù)器掛掉、網(wǎng)絡(luò)異常等)導(dǎo)致消息處理速度過慢，消息堆積可能導(dǎo)致內(nèi)存溢出，本發(fā)明增加了連接超時設(shè)置和傳輸超時設(shè)置，超過一定時長的日志直接扔掉。對于各種原因(如程序異常)導(dǎo)致的單位時間內(nèi)抓取的日志量過多的情況，本發(fā)明采用了限流處理，對于超過流量限制的消息，直接做扔棄處理。默認(rèn)TPS(吞吐量)限制為2048條/s，此限制可以設(shè)置。通過以上方案，本發(fā)明能夠透明的傳遞調(diào)用上下文，理解系統(tǒng)行為，理清后端調(diào)用關(guān)系，實(shí)現(xiàn)調(diào)用鏈跟蹤，調(diào)用路徑分析，幫助業(yè)務(wù)人員定位性能瓶頸，排查故障原因等；同時，需要對用戶盡量透明，減少對業(yè)務(wù)代碼的侵入性。本發(fā)明的整體架構(gòu)說明：Cicada主要由日志采樣模塊、日志收集模塊、日志存儲模塊、統(tǒng)計(jì)報(bào)表模塊、UI模塊這五大功模模塊組成，模塊彼此間的關(guān)系如圖3所示。Client——日志采樣模塊當(dāng)服務(wù)發(fā)生時，攔截分布式系統(tǒng)各組成部分的處理行為，記錄行為日志并將日志通過HttpPost異步發(fā)送到日志收集模塊。采用異步發(fā)送的原因是為了減少對業(yè)務(wù)響應(yīng)時間的影響。對于由于程序異常導(dǎo)致的日志發(fā)送過快的情況以及由于網(wǎng)絡(luò)異常導(dǎo)致的日志發(fā)送過慢的情況均作了處理，對于過快生成的日志，扔掉即可，同時報(bào)警提醒。對于過慢的日志，捕獲異常，同時報(bào)警提醒。功能點(diǎn)如下：1、擴(kuò)展實(shí)現(xiàn)DubboFilter，利用SPI技術(shù)透明接入，做到對Dubbo服務(wù)的無侵入式跟蹤；2、利用Serverlet3.0注解申明的新特性，擴(kuò)展實(shí)現(xiàn)對Http請求的攔截，做到透明接入；3、數(shù)據(jù)采樣1)基于中間件創(chuàng)建調(diào)用上下文，生成埋點(diǎn)；2)調(diào)用上下文放在ThreadLocal，應(yīng)用透明；3)上下文數(shù)據(jù)跟隨分布式調(diào)用傳遞；4、埋點(diǎn)數(shù)據(jù)1)TraceID，使用uuid，保證全局唯一；2)事件所在的應(yīng)用、接口和方法名；3)事件類型；4)事件開始時間；5)事件耗時。5、對于其他分散的服務(wù)，或者業(yè)務(wù)邏輯中其他小粒度的埋點(diǎn)，如服務(wù)內(nèi)部的方法調(diào)用、數(shù)據(jù)庫操作、URL請求等，提供注解以及api的方式。6、消息發(fā)送至數(shù)據(jù)收集服務(wù)；7、日志發(fā)送方案1)采用HttpPOST方式，批量異步上傳數(shù)據(jù)；2)異步框架采用disruptor(一款異步調(diào)用框架)，減少對業(yè)務(wù)的影響。日志收集模塊日志收集模塊分兩個子模塊：日志接收子系統(tǒng)和日志匯總子系統(tǒng)。1、日志接收子系統(tǒng)為簡化開發(fā)和運(yùn)維，日志接收子系統(tǒng)為nginx(一個高性能的HTTP和反向代理服務(wù)器)集群。nginx接收到客戶端POST過來的消息數(shù)據(jù)，直接記錄本地文件。2、日志匯總子系統(tǒng)1)從nginx日志中讀取最新數(shù)據(jù)，記錄讀取進(jìn)度；2)數(shù)據(jù)清洗；3)異步數(shù)據(jù)存儲到ElasticSearch；采用這種方式的優(yōu)點(diǎn)是開發(fā)和運(yùn)維工作量小，方便水平擴(kuò)展，可實(shí)現(xiàn)消息堆積。日志存儲模塊，本模塊的作用如下所述：1)Span和Annotation數(shù)據(jù)存儲在ElasticSearch；2)通過traceId可以直接將span數(shù)據(jù)關(guān)聯(lián)起來；3)通過traceId和spanId可以定位所有的Annotation數(shù)據(jù)；4)統(tǒng)計(jì)結(jié)果存儲在mysql。WEB——統(tǒng)計(jì)和報(bào)表模塊定期日志統(tǒng)計(jì)，統(tǒng)計(jì)項(xiàng)包括以下：avgDuration：平均響應(yīng)時間；minDuration：最快響應(yīng)時間；maxDuration：最慢響應(yīng)時間；line95Duration：95％line最大響應(yīng)時間；line999Duration:99.9％line最大響應(yīng)時間；failureRate：請求失敗率；提供統(tǒng)計(jì)結(jié)果以及Trace數(shù)據(jù)訪問的RESTful接口。UI——前端模塊，指用戶交互界面，展示分析結(jié)果。采用前后端分離的架構(gòu)，通過ajax(一種創(chuàng)建交互式網(wǎng)頁應(yīng)用的網(wǎng)頁開發(fā)技術(shù))向統(tǒng)計(jì)端發(fā)送數(shù)據(jù)請求。為了提高頁面渲染速度，使用React框架(前端開源框架)實(shí)現(xiàn)。本發(fā)明中相關(guān)名詞解釋：ZooKeeper：分布式服務(wù)框架，是Apache(全球知名開源基金會所)Hadoop(由Apache基金會所開發(fā)的分布式系統(tǒng)基礎(chǔ)架構(gòu))的一個子項(xiàng)目，它主要是用來解決分布式應(yīng)用中經(jīng)常遇到的一些數(shù)據(jù)管理問題，如：統(tǒng)一命名服務(wù)、狀態(tài)同步服務(wù)、集群管理、同步鎖、Leader選舉、隊(duì)列管理、分布式應(yīng)用配置項(xiàng)的管理等。Cicada-collector：數(shù)據(jù)清理模塊，負(fù)責(zé)讀取日志、清洗日志、匯總?cè)罩?。Cicada-nginx：基于Tengine(知名開源WEB服務(wù)器)實(shí)現(xiàn)的日志存放模塊。RPC：RemoteProcedureCallProtocol，遠(yuǎn)程過程調(diào)用協(xié)議，它是一種通過網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。ElasticSearch：基于Lucene的搜索服務(wù)器。它提供了一個分布式多用戶能力的全文搜索引擎，基于RESTfulweb接口。Elasticsearch是用Java開發(fā)的，并作為Apache許可條款下的開放源碼發(fā)布，是當(dāng)前流行的企業(yè)級搜索引擎。設(shè)計(jì)用于云計(jì)算中，能夠達(dá)到實(shí)時搜索，穩(wěn)定，可靠，快速，安裝使用方便。POST：HTTP協(xié)議中的一個重要組成部分。POST方法一般用來向目的服務(wù)器發(fā)出更新請求，并附有請求實(shí)體。Nginx：一款輕量級的Web服務(wù)器/反向代理服務(wù)器及電子郵件(IMAP/POP3)代理服務(wù)器，并在一個BSD-like協(xié)議下發(fā)行。當(dāng)前第1頁1 2 3 當(dāng)前第1頁1 2 3