跟我學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...。

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/inc...
• 有關zipkin配置mysql基礎建表語句能夠看這裏：https://github.com/apache/inc...
• 有關zipkin自己配置文件能夠看這裏：https://github.com/apache/inc...

至此，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

• 注：這裏的0596a362d604fb01就是這個請求的traceID，0596a362d604fb01是spanID。

咱們打開zipkin-ui的界面，以下圖：

這裏咱們能夠看到這個請求的總體耗時，點擊這個請求，能夠進入到詳情頁面，查看每一個服務的耗時：

點擊對應的服務，咱們能夠看到相應的訪問時間，http請求類型、路徑、IP、tranceID、spanId等內容，以下圖：

示例代碼-Github

參考：

http://daixiaoyu.com/distribu...
http://www.ityouknow.com/spri...