跟我學SpringCloud | 第十一篇：使用Spring Cloud Sleuth和Zipkin進行分散式鏈路跟蹤

極客挖掘機發表於2019-07-11
SpringGCCloud分散式

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），全量資料用於系統優化；資料收集除了支援平臺無關和開發語言無關係統的資料收集，還包括非同步資料收集（需要跟蹤佇列中的訊息，保證呼叫的連貫性），以及確保更小的侵入性；資料展示又涉及到資料探勘和分析。雖然每一部分都可能變得很複雜，但基本原理都類似。

跟我學SpringCloud | 第十一篇：使用Spring Cloud Sleuth和Zipkin進行分散式鏈路跟蹤

服務追蹤的追蹤單元是從客戶發起請求（request）抵達被追蹤系統的邊界開始，到被追蹤系統向客戶返回響應（response）為止的過程，稱為一個“trace”。每個 trace 中會呼叫若干個服務，為了記錄呼叫了哪些服務，以及每次呼叫的消耗時間等資訊，在每次呼叫服務時，埋入一個呼叫記錄，稱為一個“span”。這樣，若干個有序的 span 就組成了一個 trace。在系統向外界提供服務的過程中，會不斷地有請求和響應發生，也就會不斷生成 trace，把這些帶有span 的 trace 記錄下來，就可以描繪出一幅系統的服務拓撲圖。附帶上 span 中的響應時間，以及請求成功與否等資訊，就可以在發生問題的時候，找到異常的服務；根據歷史資料，還可以從系統整體層面分析出哪裡效能差，定位效能優化的目標。

跟我學SpringCloud | 第十一篇：使用Spring Cloud Sleuth和Zipkin進行分散式鏈路跟蹤

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 &

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

跟我學SpringCloud | 第十一篇：使用Spring Cloud Sleuth和Zipkin進行分散式鏈路跟蹤

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的日誌，如下圖：

跟我學SpringCloud | 第十一篇：使用Spring Cloud Sleuth和Zipkin進行分散式鏈路跟蹤

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的介面，如下圖：

跟我學SpringCloud | 第十一篇：使用Spring Cloud Sleuth和Zipkin進行分散式鏈路跟蹤

這裡我們可以看到這個請求的整體耗時，點選這個請求，可以進入到詳情頁面，檢視每個服務的耗時：

跟我學SpringCloud | 第十一篇：使用Spring Cloud Sleuth和Zipkin進行分散式鏈路跟蹤

點選對應的服務，我們可以看到相應的訪問時間，http請求型別、路徑、IP、tranceID、spanId等內容，如下圖：

跟我學SpringCloud | 第十一篇：使用Spring Cloud Sleuth和Zipkin進行分散式鏈路跟蹤

示例程式碼-Github

參考：

http://daixiaoyu.com/distributed-tracing.html
http://www.ityouknow.com/springcloud/2018/02/02/spring-cloud-sleuth-zipkin.html

相關文章