十. SpringCloud Sleuth分佈式請求鏈路跟蹤

1. 概述

發現問題

在微服務框架中，一個由客戶端發起的請求在後端系統中會通過多個不一樣的服務節點調用來協同產生最後的請求結果，每個前端請求都會造成一條複雜的分佈式服務調用鏈路，鏈路中的任何一環出現高延時或錯誤都會引發整個請求最後的失敗。因此在較複雜的系統中，一個調用鏈路中會有不少個微服務，無疑咱們須要對鏈路上的微服務進行跟蹤。

解決方案

SpringCloud Sleuth就提供了一套完整的服務跟蹤的解決方案，在分佈式系統中提供了追蹤解決方案而且兼容支持了zipkin，SpringCloud Sleuth負責對微服務調用鏈路的收集整理，而zipkin負責對鏈路的展示。

2. zipkin的搭建安裝

SpringCloud從F版以後就不須要本身構建Zipkin Server了，只須要調用相關jar包便可

zipkin的jar包下載地址：https://dl.bintray.com/openzipkin/maven/io/zipkin/java/zipkin-server/

我下的是當前最新的zipkin-server-2.12.9-exec.jar。進入到該jar包的目錄，在命令行中輸入java -jar命令運行該jar文件

java -jar zipkin-server-2.12.9-exec.jar

訪問 http://localhost:9411/zipkin/ 進入zipkin監控平臺頁面

3. 調用鏈路

名詞解釋：

• Trace：相似於樹結構的Span結合，表示一條調用鏈路，存在惟一標識

• span：標識調用鏈路來源，通俗理解span就是一次請求信息

完整的調用鏈路

一條鏈路經過Trace Id惟一標識，Span標識發起的請求信息，各span經過parent id關聯起來。

整個鏈路的依賴關係以下

4. Sleuth鏈路監控展示

在須要被鏈路監控的微服務中引入以下依賴：

<!--包含了sleuth+zipkin-->
<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

好比在咱們最開始學習Eureka服務註冊中心時使用的8001微服務（服務提供方）和80微服務（服務消費方），那時候80微服務做爲服務消費方訪問8001提供的微服務，咱們如今在這兩個微服務中引入上述依賴，並在配置文件中配置zipkin和sleuth的配置信息：

spring:
  zipkin:
    base-url: http://localhost:9411
  sleuth:
    sampler:
      # 採樣率值介於0到1之間，1表示所有采集
      probability: 1

在80和8001微服務都引入了上述依賴並添加了上面的配置後，啓動Eureka服務註冊中心、8001服務提供方服務、80服務消費方服務，而後咱們用80調用8001的服務進行測試，在zipkin面板中便可查看服務調用鏈路。