序言
sleuth是spring cloud的分布式跟蹤工具，主要記錄鍊路調用資料，本身隻支援記憶體存儲，在業務量大的場景下，為拉提升系統性能也可通過http傳輸資料，也可換做rabbit或者kafka來傳輸資料。
zipkin是Twitter開源的分布時追蹤系統，可接收資料，存儲資料（記憶體/cassandra/mysql/es），檢索資料，展示資料，他本神不會直接在分布式的系統服務種trace追蹤資料，可便捷的使用sleuth來收集傳輸資料。
這樣描述，大家應該很清晰啦。
服務追蹤意義
目前流行的架構現狀，都是站在微服務架構的基礎之上，那麼勢必會産生出越來越多的服務，互相依賴調用，那麼如果服務調用關系如下圖所示。
越來越多的服務可能，調用關系就如下啦，一團亂麻，如果沒有服務之間的鍊路追蹤的記錄查詢方案，想快速定位問題，翻代碼都不知從何翻起，估計鎖定責任人更要撕逼一翻啦，哈哈。
行業方案
Google開源的 Dapper鍊路追蹤元件，并在2010年發表了論文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，這篇文章是業内實作鍊路追蹤的标杆和理論基礎，具有非常大的參考價值。
鍊路追蹤元件有如下産品，都很贊，很值得學習：
- Google的Dapper
- Twitter的Zipkin
- 阿裡的Eagleeye （鷹眼）
- 美團點評的Cat
- 新浪的Watchman
- 京東的Hydra
- 個人吳晟（華為開發者）開源的skywalking (很贊)
- 南韓團隊naver團隊開源pinpoint
有時間大家學習一番啊。
Sleuth鍊路追蹤專業術語
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注解的過程圖形化：
trace id 整個鍊路中是唯一不變的，這樣也友善查詢。
zipkin介紹
zipkin主要有四個元件：collector，storage，API，web UI。collector用于收集各服務發送到zipkin的資料，storage用于存儲這些鍊路資料，目前支援Cassandra，ElasticSearch（推薦使用，易于大規模擴充）和MySQL，API用來查找和檢索跟蹤鍊，提供給界面UI展示。
鍊路的追蹤原理：跟蹤器位于應用程式中，記錄發生的操作的時間和中繼資料，收集的跟蹤資料稱為Span，将資料發送到Zipkin的儀器化應用程式中的元件稱為Reporter，Reporter通過幾種傳輸方式（http，kafka）之一将追蹤資料發送到Zipkin收集器(collector)，然後将跟蹤資料進行存儲(storage)，由API查詢存儲以向UI提供數
具體項目搭建
上面是我的示例項目。
1.trade-zipkin-server是zipkinserver，是用來展示，搜尋，存儲trade追蹤資料用的。
2.shop-->order-->shouhou & promotion（簡單的調用鍊路，這裡是具體需要的業務鍊路追蹤的trace項目哈）。
zipkinserver配置代碼
@EnableZipkinServer
public class StartMain {
public static void main(String[] args) {
SpringApplication.run(StartMain.class, args);
}
} <dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-server</artifactId>
<version>2.11.8</version>
</dependency>
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-autoconfigure-ui</artifactId>
<version>2.11.8</version>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency> 業務項目配置
spring.sleuth.enabled=true
spring.sleuth.sampler.percentage=1
spring.zipkin.base-url=http://localhost:8087 <dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-sleuth-zipkin</artifactId>
</dependency> note：
spring.sleuth.sampler.percentage參數配置（如果不配置預設0.1），如果我們調大此值為1，可以看到資訊收集就更及時。但是當這樣調整後，我們會發現我們的rest接口調用速度比0.1的情況下慢了很多，即使在0.1的采樣率下，我們多次重新整理consumer的接口，會發現對同一個請求兩次耗時資訊相差非常大，如果取消spring-cloud-sleuth後我們再測試，會發現并沒有這種情況，可以看到這種方式追蹤服務調用鍊路會給我們業務程式性能帶來一定的影響。
zipkin收集展示資料界面如下：
seluth+zipkin資料寫入Elasticsearch，使用kibana展示
配置zipkinserver
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-autoconfigure-storage-elasticsearch-http</artifactId>
<version>2.8.4</version>
</dependency> zipkin.storage.StorageComponent=elasticsearch
zipkin.storage.type=elasticsearch
#可以做叢集，我用的本地測試沒有部署elastic叢集
zipkin.storage.elasticsearch.hosts=es.me.com
zipkin.storage.elasticsearch.cluster=iron-man
zipkin.storage.elasticsearch.index=trade-zipkin
zipkin.storage.elasticsearch.index-shards=5
zipkin.storage.elasticsearch.index-replicas=1 總結
其實，我這個案例，隻是讓你熟悉了解服務鍊路追蹤，能夠兼顧性能的整體方案如下。