導航

• 一、什么是鏈路追蹤
• 二、Spring Cloud Sleuth
• • 2.1 相關概念
• 三、Sleuth 入門案例
• 四、Zipkin 的集成
• • 4.1 Zipkin 介紹
  • 4.2 Zipkin 服務端安裝
  • 4.3 Zipkin 客戶端安裝
• 五、Zipkin 數據持久化
• • 5.1 MySQL 數據持久化
  • 5.2 Elasticsearch 數據持久化

一、什么是鏈路追蹤

在大型系統的微服務化構建中，一個系統被拆分成了許多模塊。這些模塊負責不同的功能，組合成系統，最終可以提供豐富的功能。

在這種架構中，一次請求往往需要涉及到多個服務。這些服務模塊，可能由不同的團隊開發、不同的編程語言實現、部署在了幾千臺服務器橫跨多個不同的數據中心。這樣的系統會存在一些問題：

1、如何快速發現問題？
2、如何判斷故障影響范圍？
3、如何梳理服務依賴以及依賴的合理性？
4、如何分析鏈路性能以及實時容量規劃？

有些系統通過打日志來進行埋點，然后再通過elk進行定位及分析問題，更有甚者直接遠程服務器，使用各種linux命令單手操作查看日志，隨著業務越來越復雜，這種方式低效且吃力，不能更好的管控整體系統。

全鏈路性能監控從整體維度到局部維度展示各項指標，將跨應用的所有調用鏈性能信息集中展現，可方便度量整體和局部性能，并且方便找到故障產生的源頭，生產上可極大縮短故障排除時間。同時，一個優秀的鏈路追蹤技術組件還具有更豐富好用的特性，如：

1、請求鏈路追蹤，故障快速定位（基本特性）。
2、可視化，各個階段的耗時，方便性能分析。
3、依賴優化。
4、數據分析，優化鏈路。可以得到用戶的行為路徑，匯總分析應用在很多業務場景。

二、Spring Cloud Sleuth

Spring Cloud Sleuth 是 Spring 團隊提供的鏈路追蹤技術，大量借用了 Google Dapper 的設計。
官方文檔（英文）：Spring Cloud Sleuth Reference Documentation

2.1 相關概念

• Trace
  由一組 Trace Id 相同的 Span 串連形成的樹狀結構。當請求到達分布式系統的入口時，鏈路追蹤框架會為其創建一個唯一的標識，即 Trace Id。當請求在分布式系統內部流轉時，框架始終傳遞 Trace Id，直到整個請求返回。我們可以使用使用 Trace Id 將請求串聯起來，形成一條完整的請求鏈路。
• Span
  代表一組基本的工作單元。用于統計各處理單元的延遲，當請求到達各個服務的時候，也會生成一個 Span Id，來標記開始、過程、結束。通過 Span Id 的開始、結束時間戳，就能統計 Span 的調用時間。另外，還可以獲取如事件名稱、請求信息等元數據。
• Annotation
  用于記錄一段時間內的事件。內部使用的重要注釋：

cs（Client Send）：客戶端發出請求，開始一個請求的聲明
sr（Server Received）：服務端接收到請求開始進行處理，sr - cs = 網絡延遲（服務調用的時間）
ss（Server Send）：服務端處理完畢準備發送到客戶端，ss - sr = 請求處理的時間
cr（Client Received）：客戶端接收到服務端的響應，請求結束。cr - sr = 請求的總時間

三、Sleuth 入門案例

只需在父 pom 中加入 sleuth 依賴就可以完成對 sleuth 的集成：

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

注意，這里的版本已經跟隨 Spring Cloud 的大版本，因此不需要顯式指定，Spring Cloud 的版本是：

<!-- 版本鎖定--> <dependencyManagement><dependencies><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-dependencies</artifactId><version>Greenwich.SR5</version><type>pom</type><scope>import</scope></dependency><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-alibaba-dependencies</artifactId><version>2.1.1.RELEASE</version><type>pom</type><scope>import</scope></dependency></dependencies> </dependencyManagement>

我們通過 api gateway --> order --> product 的鏈路來檢驗 sleuth 的效果：
啟動 shop-api-gateway、shop-order、shop-product 三個微服務，并將它們都注冊到 Nacos 上：

請求網關入口的訂單接口，觀察三個微服務的后臺日志：

可以看到日志中多出了一些類似 hash 碼的字符串：

[shop-api-gateway,b6c94df98edb6d99,b6c94df98edb6d99,false]
[service-order,b6c94df98edb6d99,98da32ed6abd6192,false]
[service-product,b6c94df98edb6d99,81d51b3d2b42423f,false]

這就是 sleuth 在未進行任何配置的情況下生成的鏈路追蹤信息。它的格式是：

服務名稱，traceId，spanId，是否接入外部可視化工具

四、Zipkin 的集成

4.1 Zipkin 介紹

Zipkin 是 Twitter 的一個開源項目，是一個分布式跟蹤系統，基于 Google Dapper 實現。它有助于收集故障診斷服務體系結構中的延遲問題所需的時間數據。特性包括收集和查找這些數據。

Zipkin 分為兩端，一個是服務端（有單獨的啟動程序），一個是客戶端，客戶端以maven依賴的形式集成在各個微服務中。

4.2 Zipkin 服務端安裝

1、下載Zipkin jar包

在 maven 倉庫就可以找到，直接搜索 zipkin server ：https://mvnrepository.com/artifact/io.zipkin.java/zipkin-server

2、啟動 jar 程序
將下載好的 zipkin-server-2.12.9-exec.jar 包啟動，java -jar zipkin-server-2.12.9-exec.jar，并訪問 9411 端口。

4.3 Zipkin 客戶端安裝

1、在父 pom 中加入以下依賴即可：

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

2、在各個微服務中加入以下配置信息
因為需要各個微服務向 Zipkin 服務端推送數據，因此需要配置 zipkin 服務端地址：

spring:zipkin:base-url: http://localhost:9411/ # zipkin server 的請求地址discovery-client-enabled: false # 讓 Nacos 把它當成一個 url ，而不要當成服務名sleuth:sampler:probability: 1.0 # 采樣百分比

3、測試
正常訪問下單接口，并觀察 Zipkin server 的頁面展示。

五、Zipkin 數據持久化

zipkin server 默認會將追蹤數據保存在內存中，如果想進行持久化，zipkin 支持 mysql 或 Elasticsearch 等多種持久化方式。

5.1 MySQL 數據持久化

5.2 Elasticsearch 數據持久化

總結

以上是生活随笔為你收集整理的Spring Cloud —— 链路追踪技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。