通過上一篇《分布式服務跟蹤（整合logstash）》，我們雖然已經能夠利用ELK平臺提供的收集、存儲、搜索等強大功能，對跟蹤信息的管理和使用已經變得非常便利。但是，在ELK平臺中的數據分析維度缺少對請求鏈路中各階段時間延遲的關注，很多時候我們追溯請求鏈路的一個原因是為了找出整個調用鏈路中出現延遲過高的瓶頸源，亦或是為了實現對分布式系統做延遲監控等與時間消耗相關的需求，這時候類似ELK這樣的日志分析系統就顯得有些乏力了。對于這樣的問題，我們就可以引入Zipkin來得以輕松解決。

Zipkin簡介

Zipkin是Twitter的一個開源項目，它基于Google Dapper實現。我們可以使用它來收集各個服務器上請求鏈路的跟蹤數據，并通過它提供的REST API接口來輔助我們查詢跟蹤數據以實現對分布式系統的監控程序，從而及時地發現系統中出現的延遲升高問題并找出系統性能瓶頸的根源。除了面向開發的API接口之外，它也提供了方便的UI組件來幫助我們直觀的搜索跟蹤信息和分析請求鏈路明細，比如：可以查詢某段時間內各用戶請求的處理時間等。

上圖展示了Zipkin的基礎架構，它主要有4個核心組件構成：

• Collector：收集器組件，它主要用于處理從外部系統發送過來的跟蹤信息，將這些信息轉換為Zipkin內部處理的Span格式，以支持后續的存儲、分析、展示等功能。
• Storage：存儲組件，它主要對處理收集器接收到的跟蹤信息，默認會將這些信息存儲在內存中，我們也可以修改此存儲策略，通過使用其他存儲組件將跟蹤信息存儲到數據庫中。
• RESTful API：API組件，它主要用來提供外部訪問接口。比如給客戶端展示跟蹤信息，或是外接系統訪問以實現監控等。
• Web UI：UI組件，基于API組件實現的上層應用。通過UI組件用戶可以方便而有直觀地查詢和分析跟蹤信息。

HTTP收集

在Spring Cloud Sleuth中對Zipkin的整合進行了自動化配置的封裝，所以我們可以很輕松的引入和使用它，下面我們來詳細介紹一下Sleuth與Zipkin的基礎整合過程。主要分為兩步：

***步：搭建Zipkin Server

創建一個基礎的Spring Boot應用，命名為zipkin-server，并在pom.xml中引入Zipkin Server的相關依賴，具體如下：

<parent> 
  <groupId>org.springframework.boot</groupId> 
  <artifactId>spring-boot-starter-parent</artifactId> 
  <version>1.5.10.RELEASE</version> 
  <relativePath/> 
</parent> 
<dependencies> 
  <dependency> 
    <groupId>io.zipkin.java</groupId> 
    <artifactId>zipkin-server</artifactId> 
  </dependency> 
  <dependency> 
    <groupId>io.zipkin.java</groupId> 
    <artifactId>zipkin-autoconfigure-ui</artifactId> 
  </dependency> 
</dependencies> 
<dependencyManagement> 
  <dependencies> 
    <dependency> 
        <groupId>org.springframework.cloud</groupId> 
        <artifactId>spring-cloud-dependencies</artifactId> 
        <version>Dalston.SR5</version> 
        <type>pom</type> 
        <scope>import</scope> 
    </dependency> 
  </dependencies> 
</dependencyManagement> 

• 創建應用主類ZipkinApplication，使用@EnableZipkinServer注解來啟動Zipkin Server，具體如下：

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

• 在application.properties中做一些簡單配置，比如：設置服務端口號為9411（客戶端整合時候，自動化配置會連接9411端口，所以在服務端設置了端口為9411的話，客戶端可以省去這個配置）。

spring.application.name=zipkin-server 
server.port=9411 

創建完上述工程之后，我們將其啟動起來，并訪問http://localhost:9411/，我們可以看到如下圖所示的Zipkin管理頁面：

第二步：為應用引入和配置Zipkin服務

在完成了Zipkin Server的搭建之后，我們還需要對應用做一些配置，以實現將跟蹤信息輸出到Zipkin Server。我們以之前實現的trace-1和trace-2為例，對它們做以下改造內容：

• 在trace-1和trace-2的pom.xml中引入spring-cloud-sleuth-zipkin依賴，具體如下所示。

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

• 在trace-1和trace-2的application.properties中增加Zipkin Server的配置信息，具體如下所示（如果在zip-server應用中，我們將其端口設置為9411，并且均在本地調試的話，該參數也可以不配置，因為默認值就是http://localhost:9411）。

spring.zipkin.base-url=http://localhost:9411 

測試與分析

到這里我們已經完成了接入Zipkin Server的所有基本工作，我們可以繼續將eureka-server、trace-1和trace-2啟動起來，然后我們做一些測試實驗，以對它的運行機制有一些初步的理解。

我們先來向trace-1的接口發送幾個請求：http://localhost:9101/trace-1，當我們在日志中出現跟蹤信息的***一個值為true的時候，說明該跟蹤信息會輸出給Zipkin Server，所以此時我們可以去Zipkin Server的管理頁面中選擇合適的查詢條件后，點擊Find Traces，就可以查詢出剛才在日志中出現的跟蹤信息了（也可以根據日志中的Trace ID，在頁面的右上角輸入框中來搜索），具體如下頁面所示：

點擊下方trace-1端點的跟蹤信息，我們還可以得到Sleuth收集到的跟蹤到詳細信息，其中包括了我們關注的請求時間消耗等。

點擊導航欄中的Dependencies菜單，我們還可以查看Zipkin Server根據跟蹤信息分析生成的系統請求鏈路依賴關系圖：

消息中間件收集

Spring Cloud Sleuth在整合Zipkin時，不僅實現了以HTTP的方式收集跟蹤信息，還實現了通過消息中間件來對跟蹤信息進行異步收集的封裝。通過結合Spring Cloud Stream，我們可以非常輕松的讓應用客戶端將跟蹤信息輸出到消息中間件上，同時Zipkin服務端從消息中間件上異步地消費這些跟蹤信息。

接下來，我們基于之前實現的trace-1和trace-2應用以及zipkin-server服務端做一些改造，以實現通過消息中間件來收集跟蹤信息。改造的內容非常簡單，只需要我們做項目依賴和配置文件做一些調整就能馬上實現，下面我們分別對客戶端和服務端的改造內容做詳細說明：

***步：修改客戶端trace-1和trace-2

• 為了讓trace-1和trace-2在產生跟蹤信息之后，能夠將抽樣記錄輸出到消息中間件中，我們除了需要之前引入的spring-cloud-starter-sleuth依賴之外，還需要引入zipkin對Spring Cloud Stream的擴展依賴spring-cloud-sleuth-stream以及基于Spring Cloud Stream實現的消息中間件綁定器依賴，以使用RabbitMQ為例，我們可以加入如下依賴：

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

• 在application.properties配置中去掉HTTP方式實現時使用的spring.zipkin.base-url參數，并根據實際部署情況，增加消息中間件的相關配置，比如下面這些關于RabbitMQ的配置信息：

spring.rabbitmq.host=localhost 
spring.rabbitmq.port=5672 
spring.rabbitmq.username=springcloud 
spring.rabbitmq.password=123456 

第二步：修改zipkin-server服務端

為了讓zipkin-server服務端能夠從消息中間件中獲取跟蹤信息，我們只需要在pom.xml中引入針對消息中間件收集封裝的服務端依賴spring-cloud-sleuth-zipkin-stream，同時為了支持具體使用的消息中間件，我們還需要引入針對消息中間件的綁定器實現，比如以使用RabbitMQ為例，我們可以在依賴中增加如下內容：

<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> 
 
<dependency> 
    <groupId>io.zipkin.java</groupId> 
    <artifactId>zipkin-autoconfigure-ui</artifactId> 
</dependency> 

其中，spring-cloud-sleuth-zipkin-stream依賴是實現從消息中間件收集跟蹤信息的核心封裝，其中包含了用于整合消息中間件的核心依賴、zipkin服務端的核心依賴、以及一些其他通常會被使用的依賴（比如：用于擴展數據存儲的依賴、用于支持測試的依賴等）。但是，需要注意的是這個包里并沒有引入zipkin的前端依賴zipkin-autoconfigure-ui，為了方便使用，我們在這里也引用了它。

測試與分析

在完成了上述改造內容之后，我們繼續將eureka-server、trace-1和trace-2、zipkin-server都啟動起來，同時確保RabbitMQ也處于運行狀態。此時，我們可以在RabbitMQ的控制頁面中看到一個名為sleuth的交換器，它就是zipkin的消息中間件收集器實現使用的默認主題。

***，我們使用之前的驗證方法，通過向trace-1的接口發送幾個請求：http://localhost:9101/trace-1，當有被抽樣收集的跟蹤信息時（調試時我們可以設置AlwaysSampler抽樣機制來讓每個跟蹤信息都被收集），我們可以在RabbitMQ的控制頁面中發現有消息被發送到了sleuth交換器中，同時我們再到zipkin服務端的Web頁面中也能夠搜索到相應的跟蹤信息，那么我們使用消息中間件來收集跟蹤信息的任務到這里就完成了。

完整示例：

讀者可以根據喜好選擇下面的兩個倉庫中查看trace-1和trace-2兩個項目：

Github：https://github.com/dyc87112/SpringCloud-Learning/

Gitee：https://gitee.com/didispace/SpringCloud-Learning/

【本文為51CTO專欄作者“翟永超”的原創稿件，轉載請通過51CTO聯系作者獲取授權】

戳這里，看該作者更多好文