分布式鏈路跟蹤介紹
微服務“跟蹤"可以先看幾個問題，對於一個大型的微服務架構系統，會有哪些常見問題？
如何串聯調用鏈，快速定位問題
如何厘清微服務之間的依賴關系
如何進行各個服務接口的性能分折
如何跟蹤業務流的處理
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還提供了一個非常友好的界面，來幫助分析追蹤數據。官網地址：http://zipkin.
為什么要Zipkin
因為sleuth對於分布式鏈路的跟蹤僅僅是一些數據的記錄， 這些數據我們人為來讀取和處理難免會太麻煩了，所以我們一般吧這種數據上交給Zipkin Server 來統一處理.
我們新建一個Zipkin Server項目，然后引入依賴:
<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>
在啟動類上加入注解:@EnableZipkinServer：
@EnableZipkinServer
@SpringBootApplication
public class AppSleuth {
public static void main(String[] args) {
SpringApplication.run(AppSleuth.class);
}
}
yml文件加上如下配置:
management:
metrics:
web:
server:
autoTimeRequests: false
這個配置解釋一下： 在zipkin2.7.x以后便不支持自定義服務器需要使用官方的版本或者Docker 但是如果還是要使用的話就得加上這個配置。
完成上面的步驟之后，我們啟動項目， 你會發現Zipkin 的專屬圖標， 會發現它是基於spring boot來的，然后打開瀏覽器 訪問: /zipkin/
看到這個頁面， 基本上你的zipkin server搭建完畢了
這是用來查詢分布式鏈路數據的頁面， 這里列出了查詢條件， 從第一行開始從左到右分別是：
微服務名稱（就是你配置文件里面的application name） ，
span（即上文所解釋的）名稱 ；
時間段 ；
自定義查詢條件；
一次調用鏈的持續時間；
一頁數量；
排序規則；
目前來講，我們肯定是查詢不到數據的， 我們把我們自己的微服務和 sleuth整合 並把數據上傳到zipkin server
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全采樣
然后啟動微服務並模擬一次調用鏈 我這里是用user 微服務調用了power微服務 （注意，每個微服務都需要和zipkin整合）
調用完成之后 我們去zipkin server 頁面去看看:
這里我模擬了2條請求 一個是正常的 一個是不正常的正常的就不看了 我們看看不正常的是什么樣子的
他會顯示你的微服務調用耗時並且在哪個階段出了錯誤 還會把微服務名給顯示出來（因為我這里就是在user這里出錯的 所以這里顯示的是user 如果是power微服務出錯了 那么這個微服務名就會變成power） 而且可以點擊進去查看詳情：
他會把具體的錯誤信息給你展示出來 方便錯誤的定位。
zipkin server 數據持久化問題
上面介紹了如何把分布式鏈路調用信息上傳到 zipkin server 但是 有一個問題：
當zipkin重啟后我們的分布式鏈路數據全部清空了。因為zipkin server 默認數據是存儲在內存當中， 所以當你服務重啟之后內存自然而然也就清空了。
使用Elasticsearch 做數據持久化
Elasticsearch 下載地址：https://www.elastic.co/cn/downloads/elasticsearch
下載完是個壓縮包 解壓出來 打開bin目錄 找到elasticsearch.bat文件啟動
等他啟動一會兒然后在頁面上輸入localhost:9000看見如下信息說明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把我們微服務的追蹤數據記錄下來並展示方便我們進行后續分析