一、簡介

Spring Cloud Sleuth 主要功能就是在分散式系統中提供追蹤解決方案，並且相容支援了 zipkin，你只需要在pom檔案中引入相應的依賴即可。願意瞭解原始碼的朋友直接求求交流分享技術：二一四七七七五六三三

二、服務追蹤分析

微服務架構上通過業務來劃分服務的，通過REST呼叫，對外暴露的一個介面，可能需要很多個服務協同才能完成這個介面功能，如果鏈路上任何一個服務出現問題或者網路超時，都會形成導致介面呼叫失敗。隨著業務的不斷擴張，服務之間互相呼叫會越來越複雜。

三、術語

Spring Cloud Sleuth採用的是Google的開源專案Dapper的專業術語。

• Span：基本工作單元，例如，在一個新建的span中傳送一個RPC等同於傳送一個迴應請求給RPC，span通過一個64位ID唯一標識，trace以另一個64位ID表示，span還有其他資料資訊，比如摘要、時間戳事件、關鍵值註釋(tags)、span的ID、以及進度ID(通常是IP地址) 
  span在不斷的啟動和停止，同時記錄了時間資訊，當你建立了一個span，你必須在未來的某個時刻停止它。
• Trace：一系列spans組成的一個樹狀結構，例如，如果你正在跑一個分散式大資料工程，你可能需要建立一個trace。
• Annotation：用來及時記錄一個事件的存在，一些核心annotations用來定義一個請求的開始和結束 
  • cs - Client Sent -客戶端發起一個請求，這個annotion描述了這個span的開始
  • sr - Server Received -服務端獲得請求並準備開始處理它，如果將其sr減去cs時間戳便可得到網路延遲
  • ss - Server Sent -註解表明請求處理的完成(當請求返回客戶端)，如果ss減去sr時間戳便可得到服務端需要的處理請求時間
  • cr - Client Received -表明span的結束，客戶端成功接收到服務端的回覆，如果cr減去cs時間戳便可得到客戶端從服務端獲取回覆的所有所需時間 

將Span和Trace在一個系統中使用Zipkin註解的過程圖形化：

每個顏色的表明一個span(總計7個spans，從A到G)，每個span有類似的資訊

Trace Id = X
Span Id = D
Client Sent
此span表示span的Trance Id是X，Span Id是D，同時它傳送一個Client Sent事件

spans 的parent/child關係圖形化如下： 

spring cloud提供了spring-cloud-sleuth-zipkin來方便整合zipkin實現（指的是Zipkin Client，而不是Zipkin伺服器），該jar包可以通過spring-cloud-starter-zipkin依賴來引入。

技術架構圖如下：資料和原始碼來源