Sleuth服務跟蹤大廠高頻面試題：整合 Zipkin

Zipkin是Twitter的一個開源專案，是一個致力於收集所有服務的監控資料的分散式跟蹤系統，它提供了收集資料和查詢資料兩大介面服務。有了Zipkin我們就可以很直觀地對呼叫鏈進行檢視，並且可能很方便看出服務之間的呼叫關係以及呼叫耗費的時間。

一、建立 Zipkin 資料收集服務

首先我們需要建立一個Zipkin的專案，整合Zipkin的ui用於資料的展示和收集，pom.xml 配置如下：

<dependency> 
    <groupId>io.zipkin.java</groupId>
    <artifactId>zipkin-server</artifactId> 
</dependency>
<dependency> 
    <groupId>io.zipkin.java</groupId> 
    <artifactId>zipkin-autocongure-ui</artifactId>
</dependency>

建立啟動類：

@SpringBootApplication@EnableZipkinServerpublic class zipKinServerApplication {
    public static void main(String[] args){
        SpringApplication.run(ZipKinServerApplication.class, args);
    }
}

增加配置資訊：

spring.application.name = fangjia-zipkinserver.port=9411

到此為止，Zipkin 的服務就建立好了。啟動後訪問   就可以看到管理頁面了，如下圖所示。

二、專案整合 Zipkin 傳送呼叫鏈資料

在之前的文章中，我們只是整合了  Spring Cloud Sleuth，然後將跟蹤資訊輸出到日誌中。現在，Zipkin的服務建立好了，需要將鏈路跟蹤的資訊傳送給Zipkin的收集服務。

需要在專案中新增如下依賴：

<dependency> 
    <groupId>org.springframework.cloud</ groupId> 
    <artifactId>spring-cloud-starter-zipkin</artifactId> 
</dependency>

在屬性檔案中可以配置 Zipkin 的地址，預設是  http:// 127.0.1:9411  ，這樣才能將跟蹤的資料傳送到執行的收集服務中。

# 配置zipKin Server的地址
spring.zipkin.base-url = 

然後我們啟動之前的服務、訪問介面，就可以看到資料已經能夠在 Zipkin 的 Web 頁面中了，如下圖所示。

三、抽樣採集資料

在實際使用中可能呼叫了10次介面，但是Zipkin中只有一條資料，這是因為收集資訊是有一定比例的，這並不是bug。Zipkin 中的資料條數與呼叫介面次數預設比例是0.1，當然我們也可以透過配置來修改這個比例值：

# zipkin抽樣比例 
spring.sleuth.sampler.percentage= 1

之所以有這樣的一個配置，是因為在高併發下，如果所有資料都採集，那這個資料量就太大了，採用抽樣的做法可以減少一部分資料量，特別是對於Http方式去傳送採集資料，對效能有很大的影響。

四、用RabbitMQ代替Http傳送呼叫鏈資料

雖然有基於取樣的收集方式，但是資料的傳送採用Http還是對效能有影響。如果 Zipkin 的服務端在重啟或者掛掉了，那麼將丟失部分採集資料。為了解決這些問題，我們將整合  spring-cloud-sleuth-zipkin-stream ，用 RabbitMQ 來傳送採集資料，利用訊息佇列來提高傳送效能，保證資料不丟失。

首先改造我們的Zipkin專案，增加steam的依賴：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-sleuth-zipkin-stream</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-stream-rabbit</artifactId>
</dependency>

然後在啟動類上加上  @EnableZipkinStreamServer 註解，把之前的  @EnableZipkinServer 去掉。屬性檔案中增加 RabbitMQ 的連線配置：

# rabbitmq 配置
spring.rabbitmq.addresses=amqp://192.168.10.47:5672
spring.rabbitmq.username=yinjihuanspring.rabbitmq.password=123456

接下來我們就要改造需要跟蹤的具體服務了，也就是要加入 RabbitMQ 的依賴資訊，採用 RabbitMQ 來替換之前的Http傳送資料的方式，依賴如下：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-sleuth-zipkin-stream</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-stream-rabbit</artifactId>
</dependency>

屬性檔案中也還是增加 RabbitMQ 的連線配置：

# rabbitmq配置
spring.rabbitmq.addresses=amqp://192.168.10.47:5672
spring.rabbitmq.username=yinjihuanspring.rabbitmq.password=123456

到這裡整合就已經完成了，記得去掉之前配置的  spring.zipkin.base-url 。因為我們現在利用 RabbitMQ 來傳送資料了，所以這個配置不需要了。

五、用Elasticsearch儲存呼叫鏈資料

目前我們收集的資料都是存在 Zipkin 服務的記憶體中，服務一重啟這些資料就沒了，我們需要將這些資料持久化。我們可以將其儲存在MySQL中，實際使用中資料量可能會比較大，所以MySQL並不是一種很好的選擇，可以選擇用  Elasticsearch 來儲存資料， Elasticsearch 在搜尋方面有先天的優勢。

改造我們的 Zipkin 專案，增加  Elasticsearch 儲存的依賴：

<dependency>
    <groupId>io.zipkin.java</groupId>
    <artifactId>
    zipkin-autoconfigure-storage-elasticsearch-http
    </artifactId>
    <version>1.24.0</version>
    <optional>true</optional>
</dependency>

屬性配置中指定 Zipkin 的儲存方式以及配置  Elasticsearch 的連線資訊：

zipkin.storage.StorageComponent=elasticsearch
zipkin.storage.type=elasticsearch
zipkin.storage.elasticsearch.cluster=elasticsearch-zipkin-cluster
zipkin.storage.elasticsearch.hosts=127.0.0.1:9300
zipkin.storage.elasticsearch.max-requests=64
zipkin.storage.elasticsearch.index=zipkin
zipkin.storage.elasticsearch.index-shards=5
zipkin.storage.elasticsearch.index-replicas=1

重啟服務，然後收集一些資料，我們可以透過兩種方式來驗證資料是否儲存到了  Elasticsearch 中。

• 可以重啟 Zipkin 服務，然後看看資料是否還存在，如果存在則證明資料已經是持久化了。

• 可以透過檢視  Elasticsearch 中的資料來確認資料有沒有儲存成功，訪問  Elasticsearch 的地址檢視當前所有的索引資訊： cat/indices 。 可以看到當前節點下面有哪些索引，如果看到有以 zipkin 開頭的就說明索引建立了，接著直接查詢這個索引下是否有資料即可認證是否儲存成功，訪問   索引名稱 /search 即可。

喜歡這篇文章的朋友們可以關注個人簡介中的公眾號