聲明：本文根據魯班學院商鞅老師課程文檔整理得來
幫助：本文涉及到的詳細代碼請參考：https://github.com/LoveWK/mySpringCloud.git
sleuth的介紹：
spring Cloud Sleuth為 spring Cloud提供了分布式跟蹤的解決方案，它大量借用了Google Dapper、 Twitter Zipkin和 Apache HTrace的設計，先來了解一下 Sleuth的術語， Sleuth借用了 Dapper的術語。
span（跨度）：基本工作單元。 span用一個64位的id唯一標識。除ID外，span還包含其他數據，例如描述、時間戳事件、鍵值對的注解（標簽）， spanID、span父 ID等。 span被啟動和停止時，記錄了時間信息。初始化 span被稱為"rootspan"，該 span的 id和 trace的 ID相等。
trace（跟蹤）：一組共享"rootspan"的 span組成的樹狀結構稱為 traceo trac也用一個64位的 ID唯一標識， trace中的所有 span都共享該 trace的 ID
annotation（標注）： annotation用來記錄事件的存在，其中，核心annotation用來定義請求的開始和結束。
CS（ Client sent客戶端發送）：客戶端發起一個請求，該 annotation描述了span的開 始。
SR（ server Received服務器端接收）：服務器端獲得請求並准備處理它。如果用 SR減去 CS時間戳，就能得到網絡延遲。c)
SS（ server sent服務器端發送）：該 annotation表明完成請求處理（當響應發回客戶端時）。如果用 SS減去 SR時間戳，就能得到服務器端處理請求所需的時間。
CR（ Client Received客戶端接收）： span結束的標識。客戶端成功接收到服務器端的響應。如果 CR減去 CS時間戳，就能得到從客戶端發送請求到服務器響應的所需的時間
Spring Cloud Sleuth可以追蹤10種類型的組件：async、Hystrix，messaging，websocket，rxjava，scheduling，web（Spring MVC Controller，Servlet），webclient（Spring RestTemplate）、Feign、Zuul
下面我們通過一張圖來看一下一個簡單的微服務調用鏈：
這張圖是spring cloud 官方給出的示例圖
圖片詳細講了我們上文所說的概念在調用鏈中 處於什么狀態以及改變
sleuth整合Zipkin實現分布式鏈路跟蹤：
Zipkin簡介:
Zipkin是 Twitter開源的分布式跟蹤系統，基於 Dapper的論文設計而來。它的主要功能是收集系統的時序數據，從而追蹤微服務架構的系統延時等問題。 Zipkin還提供了一個非常友好的界面，來幫助分析追蹤數據。
為什么要使用Zipkin
因為sleuth對於分布式鏈路的跟蹤僅僅是一些數據的記錄， 這些數據我們人為來讀取和處理難免會太麻煩了，所以我們一般吧這種數據上交給Zipkin Server 來統一處理.
怎么使用ZipKin?
首先編寫一個Zipkin Server
我們創建一個新的module，引入相關依賴。
<dependencies>
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-autoconfigure-ui</artifactId>
<version>2.8.4</version>
</dependency>
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-server</artifactId>
<version>2.8.4</version>
</dependency>
</dependencies>
然后寫啟動類，並在啟動類上加上@EnableZipkinServer注解
填寫配置信息
management:
metrics:
web:
server:
autoTimeRequests: false
server:
port: 9000
注意：
在zipkin2.7.x以后便不支持自定義服務器需要使用官方的版本或者Docker 但是如果還是要使用的話就得加上這個配置。
完成上面的步驟之后，我們啟動項目，然后訪問/zipkin/
到這里，我們的ZipKin server就搭建完成了。
這是用來查詢分布式鏈路數據的頁面， 這里列出了查詢條件， 從第一行開始從左到右分別是：
微服務名稱（就是你配置文件里面的application name） ，
span（即上文所解釋的）名稱 ，
時間段 ，
自定義查詢條件，
一次調用鏈的持續時間，
一頁數量，
排序規則
sleuth微服務整合Zipkin
首先在我們的微服務中加入相關依賴，我們需要依賴sleuth 和 sleuth與zipkin的整合依賴:
<!--sleuth 和 sleuth與zipkin的整合依賴-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
然后在我們的微服務中加入以下配置：
spring:
zipkin:
base-url: http://localhost:9000 #指定Zipkin server地址
sleuth:
sampler:
probability: 1.0 #request采樣的數量 默認是0.1 也即是10% 顧名思義 采取10%的請求數據 因為在分布式系統中，數據量可能會非常大，因此采樣非常重要。我們示例數據少最好配置為1全采樣
power微服務一樣的配置即可：
然后啟動微服務並模擬一次調用鏈 我這里是用user 微服務調用了power微服務 （注意，每個微服務都需要和zipkin整合）
調用完成之后 我們去zipkin server 頁面去看看:
首先通過user微服務調用power微服務：
然后我們去zipkin server 頁面去看看:
點擊查看詳細信息：
zipkin server 數據持久化問題
剛剛我們介紹了如何把分布式鏈路調用信息上傳到 zipkin server 但是 有一個問題：當zipkin重啟后我們的分布式鏈路數據全部清空了。
因為zipkin server 默認數據是存儲在內存當中， 所以當你服務重啟之后內存自然而然也就清空了。
使用Elasticsearch 做數據持久化
我們這里借用ES來做數據持久化， 當然 還可以用ELK來做， 我們這里演示ES
Elasticsearch 下載地址：https://www.elastic.co/cn/downloads/elasticsearch
下載完是個壓縮包 解壓出來 打開bin目錄 找到elasticsearch.bat文件啟動
等他啟動一會兒然后在頁面上輸入localhost:9200看見如下信息說明Elasticsearch 啟動好了：
zipkin 與 Elasticsearch整合：
首先 我們在我們的zipkin server里面引入依賴
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-autoconfigure-storage-elasticsearch-http</artifactId>
<version>2.3.1</version>
</dependency>
然后在yml加入配置：
zipkin:
storage:
type: elasticsearch
elasticsearch:
cluster: elasticsearch
hosts: http://localhost:9200
index: zipkin
至此 zipkin的數據便和Elasticsearch整合起來了，現在再啟動zipkin server 並且存儲幾條數據， 就算重啟， 數據還會在上面。
微服務總結
由上圖可以發現， spring cloud 把各個組件相互配合起來， 整合成一套成熟的微服務架構體系
其中， 由eureka做服務注冊與發現，很好的把各個服務鏈接起來
ribbon+fegin提供了微服務的調用和負載均衡解決方案
hystrix 負責監控微服務之間的調用情況，以及降級和熔斷保護
Hystrix dashboard監控Hystrix的熔斷情況以及監控信息以圖形化界面展示
spring cloud config 提供了統一的配置中心服務
所有外來的請求由zuul統一進行路由和轉發，起到了API網關的作用
Sleuth+Zipkin把我們微服務的追蹤數據記錄下來並展示方便我們進行后續分析