[發明專利]一種分布式跟蹤系統的實時數據分析引擎

在審

• 申請號: 202011058075.7
• 申請日: 2020-09-30
• 公開（公告）號: CN112099977A
• 公開（公告）日: 2020-12-18
• 發明（設計）人: 汪燁;陳駿武;姜波
• 申請（專利權）人: 浙江工商大學
• 主分類號: G06F9/54
• 分類號: G06F9/54;G06F9/50
• 代理公司: 杭州浙科專利事務所(普通合伙) 33213
• 代理人: 楊小凡

本發明公開了一種分布式跟蹤系統的實時數據分析引擎，包括數據處理模塊及與數據處理模塊連接的數據采集模塊和數據分析模塊，所述的數據采集模塊和數據處理模塊通過數據接收模塊連接，數據接收模塊和數據處理模塊之間采用Kafka集群作為中間層，所述Kafka與數據接收模塊中的數據接收節點之間采用異步傳輸方式，Kafka統計特定時間間隔內每個URL的訪問的響應時間，數據處理模塊采用基于時間窗口的數據預聚合，通過比較響應時間對應的字段，進行數據聚合，并將新數據添加到聚合的結果中，數據預聚合的結果存儲在Redis緩存中，提取數據匯總結果并存儲，同時刪除Redis緩存中的數據。

技術領域

本發明涉及分布式應用程序技術領域，尤其是涉及了一種分布式跟蹤系統的實時數據分析引擎。

背景技術

典型的分布式跟蹤系統主要由3個部分組成：數據收集、數據存儲、數據展示。根據分布式系統的大小不同，每一部分的結構又還會根據實際情況進行相應的變化。例如，對于大規模分布式系統而言，數據存儲可分為實時數據和全量數據兩部分，實時數據用于故障排查（Trouble Shooting），全量數據用于系統優化；數據收集除了支持平臺無關和開發語言無關系統的數據收集，還包括異步數據收集；數據展示涉及到數據的挖掘與分析。分布式跟蹤系統使用戶能夠通過分布在多個應用程序、服務和數據庫以及代理等中介上的軟件系統來進行跟蹤請求。這樣做的好處是可以更深入地了解軟件系統中發生的情況。這些系統生成圖形表示，顯示請求步驟和花費的時間資源。

現代微服務體系結構技術的最新進展使構建大規模分布式應用程序成為可能。通過利用大量協作的服務節點以分散的方式，應用程序可以潛在地實現高可伸縮性、可用性、可靠性和QoS/性能。分布式跟蹤系統在微服務執行期間收集數據，后端數據分析引擎收集、分析數據并構建服務節點的調用拓撲序列。但是，收集的數據的無序性、相關性、并發性和突發性給后端數據分析引擎帶來了以下挑戰：1）需要有效的數據傳輸和并發的數據接收。對于數據收集節點來說，使用HTTP請求的數據傳輸效率很低，由于分布式跟蹤系統中收集數據的并發性，數據接收節點應支持并發數據并提供可伸縮性；2）分布式應用中微服務調用拓撲的實時分析。從分布式跟蹤系統中收集的用于調用拓撲的數據是無序的和相關的，傳統的數據存儲和分析方案可以相互協作的對相關和無序的數據進行分析，但是，它們只提供離線數據處理，并且在處理期間需要密集的I/O操作，它們不能有效地支持分布式跟蹤系統的實時分析。傳統的數據流處理框架由于不包含緩存，不適用于分布式跟蹤系統的實時分析；3）在密集的數據存儲量中進行高效的數據查詢，分布式跟蹤系統的數據分析引擎無法保證每次數據突發時所收集數據的完整性，這導致了數據存儲的負擔，并可能損害數據查詢的效率；4）數據接收和處理速度不匹配。數據處理的速度遠低于數據接收的速度。這可能會導致數據傳輸效率低和數據丟失。

目前的分布式跟蹤系統理論大多數基于Google的Dapper框架， 其設計是為了追蹤在線服務系統中的請求處理過程：例如在搜索系統場景中，對于快速準確定位出現異常的環節，是十分關鍵的。但是Dapper只是為了解決請求調用這個單一問題，并不能提供全面的方案。

Zipkin 是基于Dapper 論文設計而來一款分布式實時數據跟蹤系統。Zipkin通過在事務上下文中僅傳輸跟蹤ID來通知接收者表示正在進行跟蹤，從而保證系統的安全。然后將每個報告器中收集的數據異步傳輸到收集器。收集器將這些數據存儲在數據庫中，并且Web UI通過可以使用的格式將該數據呈現出來。

Jaeger受到了Dapper和OpenZipkin的啟發，是用于監控和排查微服務的分布式系統。Jaeger的架構與Zipkin類似，不同之處在于它在每個主機上都有一個本地聚合數據的代理，代理通過UDP連接接收數據，并將其批處理后發送給收集器。收集器以Thrift協議的形式接收該數據，并將該數據存儲在Cassandra或Elasticsearch中。查詢服務可以直接訪問數據存儲并將該信息提供給Web UI。但是該分布式系統接入過程有存在一定的侵入性，并且更多專注于鏈路追蹤，日志和指標功能支持比較有限。