Spring Cloud構建微服務架構：分佈式服務跟蹤（整合zipkin）【Dalston版】

經過上一篇 《分佈式服務跟蹤（整合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頁面中也可以搜索到相應的跟蹤信息，那麼咱們使用消息中間件來收集跟蹤信息的任務到這裏就完成了。

原文地址： http://blog.didispace.com/spr...

完整示例：

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

• Github：https://github.com/dyc87112/SpringCloud-Learning/
• Gitee：https://gitee.com/didispace/SpringCloud-Learning/

若是您對這些感興趣，歡迎star、follow、收藏、轉發給予支持！

本文內容部分節選自個人《Spring Cloud微服務實戰》，但對依賴的Spring Boot和Spring Cloud版本作了升級。