SpringCloud系列教程 | 第十一篇：使用Spring Cloud Sleuth和Zipkin進行分散式鏈路跟蹤 Springboot: 2.1.6.RELEASE SpringCloud: Greenwich.SR1 如無特殊說明，本系列教程全採用以上版本在分散式服務架構中，需要對分散式 ...

SpringCloud系列教程 | 第十一篇：使用Spring Cloud Sleuth和Zipkin進行分散式鏈路跟蹤

Springboot: 2.1.6.RELEASE

SpringCloud: Greenwich.SR1

如無特殊說明，本系列教程全採用以上版本

在分散式服務架構中，需要對分散式服務進行治理——在分散式服務協同向用戶提供服務時，每個請求都被哪些服務處理？在遇到問題時，在調用哪個服務上發生了問題？在分析性能時，調用各個服務都花了多長時間？哪些調用可以並行執行？…… 為此，分散式服務平臺就需要提供這樣一種基礎服務——可以記錄每個請求的調用鏈；調用鏈上調用每個服務的時間；各個服務之間的拓撲關係…… 我們把這種行為稱為“分散式服務跟蹤”。

1. 背景

現今業界分散式服務跟蹤的理論基礎主要來自於 Google 的一篇論文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，使用最為廣泛的開源實現是 Twitter 的 Zipkin，為了實現平臺無關、廠商無關的分散式服務跟蹤，CNCF 發佈了布式服務跟蹤標準 Open Tracing。國內，淘寶的“鷹眼”、京東的“Hydra”、大眾點評的“CAT”、新浪的“Watchman”、唯品會的“Microscope”、窩窩網的“Tracing”都是這樣的系統。

2. Spring Cloud Sleuth

一般的，一個分散式服務跟蹤系統，主要有三部分：數據收集、數據存儲和數據展示。根據系統大小不同，每一部分的結構又有一定變化。譬如，對於大規模分散式系統，數據存儲可分為實時數據和全量數據兩部分，實時數據用於故障排查（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來展示數據。

2. ZipKin

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

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

Zipkin提供了可插拔數據存儲方式：In-Memory、MySql、Cassandra以及Elasticsearch。接下來的測試為方便直接採用In-Memory方式進行存儲，生產推薦Elasticsearch。

3. 快速上手

3.1 zipkin

3.1.1 zipkin下載

根據全球最大同性交友網站（github）搜索zipkin後發現，zipkin現在已經不在推薦使用maven引入jar的方式構建了，目前推薦的方案是直接down他們打好包的jar，用java -jar的方式啟動，傳送門在這裡：https://github.com/openzipkin/zipkin。

The quickest way to get started is to fetch the latest released server as a self-contained executable jar. Note that the Zipkin server requires minimum JRE 8. For example:

curl -sSL https://zipkin.io/quickstart.sh | bash -s
java -jar zipkin.jar

You can also start Zipkin via Docker.

docker run -d -p 9411:9411 openzipkin/zipkin

Once the server is running, you can view traces with the Zipkin UI at http://your_host:9411/zipkin/.

If your applications aren't sending traces, yet, configure them with Zipkin instrumentation or try one of our examples.
Check out the zipkin-server documentation for configuration details, or docker-zipkin for how to use docker-compose.

以上內容來自zipkin官方github摘錄。簡單解釋就是可以使用https下載的方式下載zipkin.jar，並使用java -jar的方式啟動，還有一種就是使用docker的方式進行啟動。

具體搭建過程我這裡就不在贅述，有不懂的可以私信或者關註公眾號留言問我。

3.1.2 zipkin啟動

zipkin的啟動命令就比較謎了。

最簡單的啟動命令為：nohup java -jar zipkin.jar >zipkin.out 2>&1 &，這時，我們使用的是zipkin的In-Memory，含義是所有的數據都保存在記憶體中，一旦重啟數據將全部清空，這肯定不是我們想要的，我們更想數據可以保存在磁碟中，可以被抽取到大數據平臺上，方便我們後續的相關性能、服務狀態分析、實時報警等功能。

這裡我把使用mysql的啟動語句分享出來，有關ES的啟動語句基本相同：

STORAGE_TYPE=mysql MYSQL_DB=zipkin MYSQL_USER=name MYSQL_PASS=password MYSQL_HOST=172.19.237.44 MYSQL_TCP_PORT=3306 MYSQL_USE_SSL=false nohup java -jar zipkin.jar --zipkin.collector.rabbitmq.addresses=localhost --zipkin.collector.rabbitmq.username=username --zipkin.collector.rabbitmq.password=password --logging.level.zipkin2=DEBUG >zipkin.out 2>&1 &

註意： 因為鏈路追蹤的數據上報量是非常大的，如果上報數據直接使用http請求的方式推送到zipkin中，很有可能會把zipkin服務或者資料庫沖崩掉，所以我在這裡增加了rabbitmq的相關配置，上報數據先推送至rabbitmq中，再由rabbitmq講數據推送至zipkin服務，這樣達到一個請求削峰填谷的作用。
有關zipkin的啟動命令可以配置的參數可以看這裡：https://github.com/apache/incubator-zipkin/tree/master/zipkin-server
有關zipkin配置mysql基礎建表語句可以看這裡：https://github.com/apache/incubator-zipkin/blob/master/zipkin-storage/mysql-v1/src/main/resources/mysql.sql
有關zipkin本身配置文件可以看這裡：https://github.com/apache/incubator-zipkin/blob/master/zipkin-server/src/main/resources/zipkin-server-shared.yml

至此，zipkin服務應該已經搭建並完成，現在我們可以訪問一下預設埠，看一下zipkin-ui具體長什麼樣子了。

3.2 Spring Cloud Sleuth 使用

我們先將上一篇用到的zuul-simple、Eureka和producer copy到本篇文章使用的文件夾中。

3.2.1 增加依賴：

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

在zuul-simple和producer兩個項目中增加sleuth和rabbitmq的依賴。

3.2.2 配置文件

增加有關rabbitmq和sleuth的配置，這裡我僅給出zuul的配置文件，producer的配置同理。

server:
  port: 8080
spring:
  application:
    name: spring-cloud-zuul
  rabbitmq:
    host: host
    port: port
    username: username
    password: password
  sleuth:
    sampler:
      probability: 1.0
zuul:
  FormBodyWrapperFilter:
    pre:
      disable: true
eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/

註：spring.sleuth.sampler.probability的含義是鏈路追蹤採樣率，預設是0.1，我這裡為了方便測試，將其改成1.0，意思是百分之百採樣。

3.2.3 測試

這裡我們依次啟動Eureka、producer和zuul-simple。

打開瀏覽器，訪問測試連接：http://localhost:8080/spring-cloud-producer/hello?name=spring&token=123

這時我們先看zuul的日誌，如下圖：

2019-07-07 23:09:28.529  INFO [spring-cloud-zuul,0596a362d604fb01,0596a362d604fb01,true] 20648 --- [nio-8080-exec-1] c.s.zuulsimple.filter.TokenFilter