分布式鏈路呼叫跟蹤系統

一. 為什麼需要分布式呼叫跟蹤

隨著分布式服務架構的流行，特別是微服務等設計理念在系統中的應用，系統架構變得越來越分散，如下圖所示:

分布式服務拆分以後，系統變得日趨複雜，業務的呼叫鏈也越來越長，如何快速定位線上故障，就需要依賴分布式呼叫跟蹤技術。可以看到，隨著服務的拆分，系統的模組變得越來越多，不同的模組可能由不同的團隊維護，乙個請求可能會涉及幾十個服務的協同處理，牽扯到多個團隊的業務系統。

假設現在某次服務呼叫失敗，或者出現請求超時，需要定位具體是哪個服務引起的異常，哪個環節導致的超時，就需要去每個服務裡檢視日誌，這樣的處理效率是非常低的。

另外，系統拆分以後，缺乏乙個自上而下全域性的呼叫 id，如何有效地進行相關的資料分析工作呢？比如電商的活動轉化率、購買率、廣告系統的點選鏈路等。如果沒有乙個統一的呼叫 id 來記錄，只依靠業務上的主鍵等是很難實現的，特別是對於一些大型**系統，如**、京東等，這些問題尤其突出。

二. 分布式鏈路呼叫跟蹤的業務場景

分布式呼叫跟蹤技術就是解決上面的業務問題，即通過呼叫鏈的方式，把一次請求呼叫過程完整的串聯起來，這樣就實現了對請求呼叫路徑的監控。

分布式呼叫鏈其實就是將一次分布式請求還原成呼叫鏈路，顯式的在後端檢視一次分布式請求的呼叫情況，比如各個節點上的耗時、請求具體打到了哪台機器上、每個服務節點的請求狀態等。

一般來說，分布式呼叫跟蹤可以應用在以下的場景中。

1）故障快速定位：通過呼叫鏈跟蹤，一次請求的邏輯軌跡可以完整清晰地展示出來。在開發的過程中，可以在業務日誌中新增呼叫鏈 id，還可以通過呼叫鏈結合業務日誌快速定位錯誤資訊。

2）各個呼叫環節的效能分析：在呼叫鏈的各個環節分別新增呼叫時延，並分析系統的效能瓶頸，進行針對性的優化。

3）各個呼叫環節的可用性，持久層依賴等：通過分析各個環節的平均時延、qps 等資訊，可以找到系統的薄弱環節，對一些模組做調整，比如資料冗餘等。

4）資料分析等：呼叫鏈是一條完整的業務日誌，可以得到使用者的行為路徑，並彙總分析。

1）apache skywalking。

官網 2）springcloud sleuth，它整合了zipkin、htrace 鏈路追蹤工具，用服務鏈路追蹤來快速定位問題。

3）cat。

4）**鷹眼tracing