分佈式追蹤系統的設計與實踐 1

微服務的現狀：

• 某個核心服務掛了，導致出現大量報警，如何快速確定哪個服務出現問題？

• 某個核心服務掛起，導致大量報錯，如何快速確定那個服務出了問題？

• 應用程序有性能瓶頸，怎樣確定瓶頸在哪？

• App 請求響應延遲高，怎麼樣確定是由哪些服務導致的？

• 線上發佈了服務，怎麼知道它一切正常？

在微服務體系中，一般不會同級調度，但交叉調用還是挺多的。

我們要解決上述的問題，比較好的方法是構建分佈式請求追蹤系統。

目前這類系統的實現有很多方案，開源的有：

• 京東 Hydra

• Twitter Zipkin

• Apache SkyWalking（APM）

• PinPoint（APM）

在 SpringCloud Netflix 和 Istio 中，Zipkin 被廣泛使用。

分佈式追蹤系統應該能做到便於使用，即通過引入一個 jar 包，就可以做分佈式請求追蹤。跟蹤三方面內容:

1. RT: 響應時間

2. 處理結果：成功、失敗、超時、異常。

3. 請求鏈路的拓撲關係。

上面三個目標怎麼實現？通過日誌的方式來收集上面的信息，日誌誰來寫？jar 包。日誌會貫穿多個層面，日誌的 ID 叫 trace ID，traceID 由網關層生成。

基於日誌的分佈式追蹤系統的好處是：

業務侵入小

將每個系統分散的日誌聚合起來，並進行海量日誌分析，從而生成有價值的數據。

關於調用鏈：每次請求都生成一個全局唯一的 ID（TraceID），通過它將不同的系統生成的日誌串在一起，重組成調用鏈，時期價值達到 1+1>2 的效果。開發人員通過分佈式追蹤系統請求跟蹤鏈拍橙 V 查問題。可以對多個請求進行統計和分析。

分佈式追蹤系統的幾個場景：

1. 調用鏈跟蹤：一次請求調用過程的展示，以圖形化方式輸出各個微服務端集羣之間的調用關係，並記錄整個過程的消耗時間，協助發發人員分析整個系統的瓶頸點與熱點、從而優化系統。

2. 調用鏈路徑分析：對多條調用鏈進行分析，整理成集羣之間的調用關係，計算出整個鏈路的關鍵節點，直接依賴，間接依賴，依賴強度等。

3. 調用來源分析：針對某一特定的集羣，整理出其他集羣對其的調用情況，防止錯誤調用的發生。

4. 調用量統計：實時統計各個集羣的調用次數、QPS、平均耗時、最大耗時等信息，開發人員可以根據相關的信息進行容量規劃。

5. 監控請求調用量：開發人員通過自動以正則表達式、對匹配該正則的 URL 的請求進行實時監控，包括調用次數、QPS、平均耗時、最大耗時、最小耗時。

根據以上的需求，分佈式追蹤系統的設計圖如下：

上圖中，java 探針就是對應用做了一個切面的攔截。在請求開始和結束位置都注入代碼。日誌的上報，是個 UDP 的請求。有一個點需要考慮，業務邏輯層調用數據訪問層，可能有多個數據訪問層，怎麼記錄它的時序呢？怎麼完成的把調用時序還原呢？

爲了保證日誌的時序，需要使用三個標識：

• 請求鏈唯一標識：TraceID

• 時序標識：SequenceID (每層從 1 開始底層)

• 深度標識：DepthID（小數點的個數）

關於幾種開源分佈式追蹤系統的對比，可以參照下文：

https://www.jianshu.com/p/0fbbf99a236e

• Zipkin 是 Twitter 開源的調用鏈分析工具，目前基於 springcloud sleuth 得到了廣泛的使用，特點是輕量，使用部署簡單。

• Pinpoint 是韓國人開源的基於字節碼注入的調用鏈分析，以及應用監控分析工具。特點是支持多種插件，UI 功能強大，接入端無代碼侵入。

• SkyWalking 是本土開源的基於字節碼注入的調用鏈分析，以及應用監控分析工具。特點是支持多種插件，UI 功能較強，接入端無代碼侵入。目前已加入 Apache 孵化器。

• CAT 是大衆點評開源的基於編碼和配置的調用鏈分析，應用監控分析，日誌採集，監控報警等一系列的監控平臺工具。

Skywalking 和 PinPoint 各有優劣勢，不過從我看到國內的使用案例，SkyWalking 更多一些。我們查看兩者以及 Zipkin 在 github 的評星：

Skywalking 是最高的：

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/-c0u6vha247T7ZapLz4ZQQ