技術背景

在微服務架構中，隨著業務發展，系統拆分導致系統調用鏈路愈發復雜，一個看似簡單的前端請求可能最終需要調用很多次後端服務才能完成，那麽當整個請求出現問題時，我們很難得知到底是哪個服務出了問題導致的，這時就需要解決一個問題，如何快速定位服務故障點，於是，分布式系統調用鏈追蹤技術就此誕生了。

ZipKin

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

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

Zipkin提供了可插拔數據存儲方式：In-Memory、MySql、Cassandra以及Elasticsearch。我們可以跟根據需求選擇不同的存儲方式，生成環境一般都需要持久化。我們這裏采用elasticsearch作為zipkin的數據存儲器。

Spring Cloud Sleuth

一般而言，一個分布式服務追蹤系統，主要有三部分組成：數據收集、數據存儲和數據展示。

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

耗時分析: 通過Sleuth可以很方便的了解到每個采樣請求的耗時，從而分析出哪些服務調用比較耗時。

可視化錯誤: 對於程序未捕捉的異常，可以通過集成Zipkin服務界面上看到。

鏈路優化: 對於調用比較頻繁的服務，可以針對這些服務實施一些優化措施。

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

實現案例

在早前的Spring Cloud版本裏是需要自建zipkin服務端的，但是從SpringCloud2.0 以後，官方已經不支持自建Server了，改成提供編譯好的jar包供用戶使用。

下載鏡像

此前請先安裝好docker環境，使用以下命令分別拉取zipkin和elasticsearch鏡像。

docker pull openzipkin/zipkin
docker pull docker.elastic.co/elasticsearch/elasticsearch:6.3.0

通過 docker images 查看下載鏡像。

編寫啟動文件

創建如下文件夾結構。

dockerfile
    |- elasticsearch
    |    |- data
    |- docker-compose.yml

docker-compose.yml

version: "3"
services:

  elasticsearch:
    image:  docker.elastic.co/elasticsearch/elasticsearch:6.3.0
    container_name: elasticsearch
    restart: always
    networks:
      - elk
    ports:
      - "9200:9200"
      - "9300:9300"
    volumes:
       - ../elasticsearch/data:/usr/share/elasticsearch/data

  zipkin:
    image: openzipkin/zipkin:latest
    container_name: zipkin
    restart: always
    networks:
      - elk
    ports:
      - "9411:9411"
    environment:
      - STORAGE_TYPE=elasticsearch
      - ES_HOSTS=elasticsearch

networks:
    elk:

關於docker-compose.yml 文件格式及相關內容請自行百度了解。

啟動服務

命令模式進入dockerfile目錄，執行啟動命令如下。

docker-compose up -d

執行過程如下圖所示。

執行完成之後，通過 docker ps 命令查看，發現zipkin和elasticsearch確實啟動起來了。

到這裏，zipkin服務端就搭建起來了，訪問 http://localhost:9411，效果如下，因為還沒有客戶端，所以還沒有數據。

zipkin服務端已經搭建完成了，接下來我們來實現客戶端。

添加依賴

修改 spring-cloud-consul-consumer 項目Maven配置，添加zipkin依賴。

pom.xml

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

添加配置

修改配置文件，添加如下zipkin配置。

spring:
  zipkin:
    base-url: http://localhost:9411/
  sleuth:
    sampler:
      probability: 1 #樣本采集量，默認為0.1，為了測試這裏修改為1，正式環境一般使用默認值。

application.yml

測試效果

先後啟動註冊中心、服務提供者、服務消費者。

反復訪問幾次 http://localhost:8521/ribbon/call，產生zipkin數據。

再次訪問 http://localhost:9411， 發現出現了我們剛剛訪問的服務，選擇並點擊追蹤。

點擊追蹤之後，頁面顯示了相關的服務調用信息。

點擊調用記錄查看詳情頁面，可以看到每一個服務所耗費的時間和順序。

分布式鏈路追蹤（Sleuth、Zipkin）