Java生鮮電商平台-SpringCloud分布式請求跟蹤系統設計與實踐
Java生鮮電商平台微服務現狀
- 某個服務掛了，導致上游大量報警，如何快速定位哪個服務出問題？
- 某個核心掛了，導致大量報錯，如何快速定位哪里出了問題？
- 應用程序的性能瓶頸？
- 線上發布了服務，怎么知道一切正常？
- App響應延遲，怎么確定有哪些服務導致？
如何解決
- 業務端去解決，通過日志，grep，awk，sed等等定位。
- 分布式請求跟蹤系統。(幫助開發人員快速理解系統行為，快速定位問題的工具，分布式請求跟蹤系統應運而生)
產品
設計需求
-
基於日志的分布式請求跟蹤系統
- 業務侵入小
- 將每個系統分散的日志聚合起來，並進行海量數據日志分析。
-
核心---調用鏈
- 每次請求生成一個全局唯一id，通過它將不同系統生成的日志串在一起，重組成調用鏈，使其價值達 1+1》2的效果。
- 開發人員通過分布式請求跟蹤鏈排查問題
- 對多個請求進行統計和分析。
設計目標
- 低侵入性
- 作為非業務組件，盡量減少侵入或者無侵入其他業務系統，對於使用方透明，減少業務開發人員的負擔。
- 靈活的應用策略
- 使使用方可以根據需求，自定義收集數據的使用范圍和粒度。
- 時效性
- 從數據的產生和收集，到數據的分析與處理，再到最終的頁面展現，盡可能快。
- 可視化
- 使用場景友好的用戶視角，可讀性高。
分布式請求跟蹤系統使用的場景
場景一 調用鏈跟蹤
一次請求調用過程的展示，以圖形化方式梳理各個為服務端集群之間的調用關系，並記錄整個調用過程的耗時，協助開發人員分析整個系統的瓶頸點與熱點，從而優化系統。
一次調用的耗時
場景二 調用鏈的路徑分析
對多條調用鏈進行分析，整理出集群之間的調用關系，計算出整個調用鏈路的關鍵節點、直接依賴、間接依賴 強度等等
場景三 調用來源分析
針對某一特定集群，整理出其他集群對其調用情況，防止錯誤調用情況的發生。
image
場景四 調用量統計
實時統計各個計算的調用次數、QPS、平均耗時、最大耗時等信息，開發人員可以根據相關信息進行容量規划。
場景五 監控請求調用量
開發人員通過自定義正則表達式，對匹配該規則的URL進行實時監控，包括調用次數等等。。。。。。
整體架構設計
-
埋點和生成日志
-
java探針-javaagent技術，通過本地socket將收集到的數據實時發送給本機上的日志收集節點agent，將本機上的多個java探針的日志數據發送到日志收集服務器集群。
-
-
收集和存儲日志
-
日志收集服務器集群對數據進行格式化處理之后，分成三個工作流進行后續處理
-
-
匯總和重組調用鏈
-
分析和統計調用鏈
- 原始數據直接存入到ES集群中，用於頁面實時調用鏈的展示
- 原始數據存入到本地的日志中，通過Flume上傳到HDFS急群眾，利用Hadoop集群定時的進行離線分析，分析后的結果存入到ES集群中，用於頁面數據分析的展示。
-
原始數據發送到Spark/Flink在線分析集群，進行QPS、平均耗時等實時數據統計，分別將計算結果保存到Redis集群和ES集群中，用於頁面實時數據統計的展示。
整體架構
埋點和生成日志
- 請求唯一標識(TraceID)
- 時序標識(SequenceID)
- 深度標識(DepthID)
重點是ID的生成，怎么生成呢？
ID體系設計
-
請求唯一標識(TraceID)網關生成
分布式id -
時序標識(SequenceID)
每層從1開始遞增，放在threadlocal里面。下一層繼承上一層的深度，加一個點。 -
深度標識(DepthID)
點的個數遞增
開源產品選擇
- Pinpoint
-
Apache SkyWalking
