一般的，一個分布式服務跟蹤系統，主要有三部分：數據收集、數據存儲和數據展示。根據系統大小不同，每一部分的結構又有一定變化。譬如，對于大規模分布式系統，數據存儲可分為實時數據和全量數據兩部分，實時數據用于故障排查(troubleshooting)，全量數據用于系統優化；數據收集除了支持平臺無關和開發語言無關系統的數據收集，還包括異步數據收集(需要跟蹤隊列中的消息，保證調用的連貫性)，以及確保更小的侵入性；數據展示又涉及到數據挖掘和分析。雖然每一部分都可能變得很復雜，但基本原理都類似。

服務追蹤的追蹤單元是從客戶發起請求(request)抵達被追蹤系統的邊界開始，到被追蹤系統向客戶返回響應(response)為止的過程，稱為一個“trace”。每個 trace 中會調用若干個服務，為了記錄調用了哪些服務，以及每次調用的消耗時間等信息，在每次調用服務時，埋入一個調用記錄，稱為一個“span”。這樣，若干個有序的 span 就組成了一個 trace。在系統向外界提供服務的過程中，會不斷地有請求和響應發生，也就會不斷生成 trace，把這些帶有span 的 trace 記錄下來，就可以描繪出一幅系統的服務拓撲圖。附帶上 span 中的響應時間，以及請求成功與否等信息，就可以在發生問題的時候，找到異常的服務；根據歷史數據，還可以從系統整體層面分析出哪里性能差，定位性能優化的目標。

Spring Cloud Sleuth為服務之間調用提供鏈路追蹤。通過Sleuth可以很清楚的了解到一個服務請求經過了哪些服務，每個服務處理花費了多長。從而讓我們可以很方便的理清各微服務間的調用關系。此外Sleuth可以幫助我們：

耗時分析: 通過Sleuth可以很方便的了解到每個采樣請求的耗時，從而分析出哪些服務調用比較耗時; 可視化錯誤: 對于程序未捕捉的異常，可以通過集成Zipkin服務界面上看到; 鏈路優化: 對于調用比較頻繁的服務，可以針對這些服務實施一些優化措施。

spring cloud sleuth可以結合zipkin，將信息發送到zipkin，利用zipkin的存儲來存儲信息，利用zipkin ui來展示數據。

這是Spring Cloud Sleuth的概念圖：

ZipKin

Zipkin 是一個開放源代碼分布式的跟蹤系統，由Twitter公司開源，它致力于收集服務的定時數據，以解決微服務架構中的延遲問題，包括數據的收集、存儲、查找和展現。

每個服務向zipkin報告計時數據，zipkin會根據調用關系通過Zipkin UI生成依賴關系圖，顯示了多少跟蹤請求通過每個服務，該系統讓開發者可通過一個 Web 前端輕松的收集和分析數據，例如用戶每次請求服務的處理時間等，可方便的監測系統中存在的瓶頸。

Zipkin提供了可插拔數據存儲方式：In-Memory、MySql、Cassandra以及Elasticsearch。接下來的測試為方便直接采用In-Memory方式進行存儲，生產推薦Elasticsearch。快速上手創建zipkin-server項目

項目依賴

org.springframework.cloud spring-cloud-starter-eureka io.zipkin.java zipkin-server io.zipkin.java zipkin-autoconfigure-ui

啟動類

@SpringBootApplication @EnableEurekaClient @EnableZipkinServer public class ZipkinApplication { public static void main(String[] args) { SpringApplication.run(ZipkinApplication.class, args); } }

使用了@EnableZipkinServer注解，啟用Zipkin服務。

配置文件

eureka: client: serviceUrl: defaultZone: http://localhost:8761/eureka/ server: port: 9000 spring: application: name: zipkin-server

配置完成后依次啟動示例項目：spring-cloud-eureka、zipkin-server項目。剛問地址:http://localhost:9000/zipkin/可以看到Zipkin后臺頁面

項目添加zipkin支持

在項目spring-cloud-producer和spring-cloud-zuul中添加zipkin的支持。

org.springframework.cloud spring-cloud-starter-zipkin

Spring應用在監測到Java依賴包中有sleuth和zipkin后，會自動在RestTemplate的調用過程中向HTTP請求注入追蹤信息，并向Zipkin Server發送這些信息。

同時配置文件中添加如下代碼：

spring: zipkin: base-url: http://localhost:9000 sleuth: sampler: percentage: 1.0

spring.zipkin.base-url指定了Zipkin服務器的地址，spring.sleuth.sampler.percentage將采樣比例設置為1.0，也就是全部都需要。

Spring Cloud Sleuth有一個Sampler策略，可以通過這個實現類來控制采樣算法。采樣器不會阻礙span相關id的產生，但是會對導出以及附加事件標簽的相關操作造成影響。 Sleuth默認采樣算法的實現是Reservoir sampling，具體的實現類是PercentageBasedSampler，默認的采樣比例為: 0.1(即10%)。不過我們可以通過spring.sleuth.sampler.percentage來設置，所設置的值介于0.0到1.0之間，1.0則表示全部采集。

這兩個項目添加zipkin之后，依次進行啟動。進行驗證

這樣我們就模擬了這樣一個場景，通過外部請求訪問Zuul網關，Zuul網關去調用spring-cloud-producer對外提供的服務。

四個項目均啟動后，在瀏覽器中訪問地址：http://localhost:8888/producer/hello?name=neo 兩次，然后再打開地址： http://localhost:9000/zipkin/點擊對應按鈕進行查看。

點擊查找看到有兩條記錄

點擊記錄進去頁面，可以看到每一個服務所耗費的時間和順序

點擊依賴分析，可以看到項目之間的調用關系

想要深入學習的同學們可以加入QQ群討論哦，QQ討論群組：984370849 706564342 歡迎加入討論我們有高階完整資源筆記分享，也有我們的群體有IT各業人員，可以快速解決在這里尋找到解決問題的辦法，沒錯，我們等著你，分享我們之間的經驗，以及我們之間共同但又不同的故事。

總結

以上是生活随笔為你收集整理的zipkin使用_Sleuth和Zipkin进行分布式链路跟踪，一点课堂（多岸学院）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。