分布式服務跟蹤實現方法與流程

2023-04-23 18:03:56

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