在微服務框架中，一個由客戶端發起的請求在後端系統中會經過多個不同的的服務節點呼叫來協同產生最後的請求結果，每一個前段請求都會形成一條複雜的分散式服務呼叫鏈路，鏈路中的任何一環出現高延時或錯誤都會引起整個請求最後的失敗。
願意瞭解原始碼的朋友直接企鵝求求：二一四七七七五六三三
Spring Cloud Sleuth提供了一套完整的服務跟蹤的解決方案。Spring Cloud Sleuth借用了Google
Dapper的術語。
Span:工作的基本單位。例如，傳送RPC是一個新的跨度，就像傳送響應到RPC一樣。Span是由一個唯一的64位ID來標識的，而另一個64位ID用於跟蹤。span還具有其他資料，如描述、時間戳事件、鍵值標註(標記)、導致它們的span的ID和程序ID(通常是IP地址)。
可以啟動和停止跨度，並跟蹤其時間資訊。 建立跨度後，必須在將來的某個時刻停止它。
啟動跟蹤的初始範圍稱為根跨度。 該範圍的ID值等於跟蹤ID。
Trace：一組span形成樹狀結構。 例如，如果執行分散式大資料儲存，則可能由PUT請求形成跟蹤。
註解：用於及時記錄事件的存在。 使用Brave工具，我們不再需要為Zipkin設定特殊事件，以瞭解客戶端和伺服器是誰，請求開始的位置以及結束位置。
cs：客戶已傳送。 客戶提出了請求。 此註釋表示跨度的開始。
sr：Server Received：伺服器端獲得請求並開始處理它。 從此時間戳中減去cs時間戳會顯示網路延遲。
ss：伺服器已傳送。 在完成請求處理時（當響應被髮送回客戶端時）註釋。 從此時間戳中減去sr時間戳會顯示伺服器端處理請求所需的時間。
cr：客戶收到了。 表示跨度的結束。 客戶端已成功收到伺服器端的響應。 從此時間戳中減去cs時間戳會顯示客戶端從伺服器接收響應所需的全部時間。
下圖顯示了Span和Trace在系統中的外觀以及Zipkin註解：

此註釋表示當前跨度的Trace Id設定為X，Span Id設定為D.此外，還發生了Client Sent事件。

Trace Id = X
Span Id = D
Client Sent
下圖顯示了跨度的父子關係：

技術架構圖：

程式碼結構圖：資料和原始碼來源