在微服務框架中，一個由客戶端發起的請求在后端系統中會經過多個不同的的服務節點調用來協同產生最后的請求結果，每一個前段請求都會形成一條復雜的分布式服務調用鏈路，鏈路中的任何一環出現高延時或錯誤都會引起整個請求最后的失敗。

愿意了解源碼的朋友直接企鵝求求：二一四七七七五六三三

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注解：

注釋的每種顏色表示跨度（有七個跨度 - 從A到G）。 請考慮以下注釋：

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

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

技術架構圖：

代碼結構圖 資料和源碼來源

總結

以上是生活随笔為你收集整理的java B2B2C Springcloud多租户电子商城系统-Spring Cloud Sleuth的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。