文檔位址：https://docs.spring.io/spring-cloud-sleuth/docs/2.2.4.BUILD-SNAPSHOT/reference/html/
git位址：https://github.com/spring-cloud/spring-cloud-sleuth/
在微服務架構中，一個由用戶端發起的請求在後端系統中會經過多個不同的服務節點調用來協同産生最後的請求結果，每一個前段請求都會形成一條複雜的分布式服務調用鍊，鍊路中的任何一環出現高延時或錯誤都會引起整個請求的失敗。
sleuth提供了一套完整的服務跟蹤的解決方案。包括鍊路追蹤（可以看到每個請求的依賴服務）、性能分析（可以看到在每個調用消耗的時間）以及通過鍊路分析程式錯誤等。
在分布式系統中提供追蹤解決方案并且相容支援了zipkin。其實就是sleuth負責監控，zipkin負責展現。
官網：https://github.com/spring-cloud/spring-cloud-sleuth
Springcloud從F版不需要自己建構ZipkinServer，隻需要下載下傳jar包運作即可。下載下傳位址：http://dl.bintray.com/openzipkin/maven/io/zipkin/java/zipkin-server/
Trace：一系列spans組成的一個樹狀結構，表示一條調用鍊路，一條鍊路通過Trace Id唯一辨別。
Span：表示調用鍊路來源，通俗的了解span就是一次請求資訊，各span通過parentid關聯起來。
Annotation：用來及時記錄一個事件的存在，一些核心annotations用來定義一個請求的開始和結束
cs - Client Sent -用戶端發起一個請求，這個annotion描述了這個span的開始
sr - Server Received -服務端獲得請求并準備開始處理它，如果将其sr減去cs時間戳便可得到網絡延遲
ss - Server Sent -注解表明請求處理的完成(當請求傳回用戶端)，如果ss減去sr時間戳便可得到服務端需要的處理請求時間
cr - Client Received -表明span的結束，用戶端成功接收到服務端的回複，如果cr減去cs時間戳便可得到用戶端從服務端擷取回複的所有所需時間
1.下載下傳
zipkin-server-2.12.9-exec.jar
2.啟動zipkin
3.通路測試，zipkin預設端口是9411
1.修改pom，增加如下依賴：
2.修改yml，增加zipkin和sleuth相關資訊
1.修改pom，增加如下依賴
2.修改yml
依次啟動eureka-》支付服務-》訂單服務，然後通路如下：
(1)通路訂單服務，訂單服務内部調用支付服務
http://localhost/consumer/pay/getServerPort
(2)檢視zipkin
(3)點選檢視請求詳情
(4)點選時間：如下
圖一：parentid為空
圖二：(也驗證了通過spanid标記服務請求，parentid标記上個請求)
其實，sleuth的資料也可以進行持久化到資料庫中。這個需要的時候再研究吧。
補充：cloud內建zipkin之後日志會自動列印traceId和spanId，格式如下：
解釋：
application name — 應用的名稱，也就是application.properties中的spring.application.name參數配置的屬性。
traceId — 為一個請求配置設定的ID号，用來辨別一條請求鍊路。
spanId — 表示一個基本的工作單元，一個請求可以包含多個步驟，每個步驟都擁有自己的spanId。一個請求包含一個TraceId，多個SpanId
export — 布爾類型。表示是否要将該資訊輸出到類似Zipkin這樣的聚合器進行收集和展示
補充：sleuth原理簡單了解
1》traceId和spanId在服務間傳遞在調用的時候通過header傳遞的 ，官方給出的圖如下：
2》在服務内部是通過MDC傳遞的，可以了解為通過ThreadLocal傳遞，官方解釋如下：
源碼如下：
(3) logback預設打出的日志會加入appname、traceId、spaceId、Export資訊，官方解釋如下：
測試：
(1)order服務日志如下：
(2) payment日志如下：
補充：Sleuth對其他相關的元件進行了內建
(1) 對@Async 異步線程池做了內建，官方解釋如下：也就是說trace資訊為同主線程一樣，每個@Async标注的異步方法會生成一個新的Span資訊。簡單的說就是traceId同主線程一樣，spanId重新生成：
【當你用心寫完每一篇部落格之後,你會發現它比你用代碼實作功能更有成就感!】