鏈路追蹤Sleuth入門
阿新 • • 發佈：2022-04-20
前言：
在一個大型的分散式專案中存在各種各樣的模組呼叫。每個模組負責不同的功能，組合成系統。
在這種架構下的系統，一次請求往往會呼叫到許許多多的微服務。這樣的跨度對於維護也是存在一定的問題。
1.如何快速發現問題？
2.如何判斷故障影響範圍？
3.如何梳理服務依賴以及依賴的合理性？
4.如何分析鏈路效能問題以及實時容量規劃？
對於這些問題我們可以採用分散式鏈路追蹤進行解決。
分散式鏈路追蹤（Distributed Tracing），就是將一次分散式請求還原成呼叫鏈路，進行日誌記錄，效能監控並將 一次分散式請求的呼叫情況集中展示。目前業界比較流行的鏈路追蹤系統如：Twitter的Zipkin，阿里的鷹眼，美團的Mtrace，大眾點評的cat等，大部分都是基於google發表的Dapper。Dapper闡述了分散式系統， 特別是微服務架構中鏈路追蹤的概念、資料表示、埋點、傳遞、收集、儲存與展示等技術細節。
比如各個服務節點上的耗時、請求具體到達哪臺機器上、每個服務節點的請求狀態等等。
對於鏈路追蹤Spring也提供了其對應的方法：Spring Cloud Sleuth
Spring Cloud Sleuth 主要功能就是在分散式系統中提供追蹤解決方案，並且相容支援了 zipkin，只需要在pom檔案中引入相應的依賴即可。流程圖：
鏈路追蹤Sleuth入門
（1）在需要的微服務下新增配置依賴 <!--Sleuth鏈路追蹤依賴-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
（2）修改配置檔案
修改application.yml新增日誌級別
logging: level: root: INFO org.springframework.web.servlet.DispatcherServlet: DEBUG org.springframework.cloud.sleuth: DEBUG #鏈路追蹤日誌
（3）檢視效果
http://localhost:8001/admin/category/demo.do/1
訪問category微服務的demo.do服務。該服務會去遠端呼叫demo微服務的demo.do服務。
訪問成功後我們可以觀察微服務的控制檯日誌：
Category微服務控制檯：
Demo微服務控制檯：
呼叫之後，我們可以在控制檯觀察到sleuth的日誌輸出。
其中 藍色框中的是TraceId，後面跟著的綠色框中的是SpanId，依次呼叫有一個全域性的TraceId，將呼叫鏈 路串起來。仔細分析每個微服務的日誌，不難看出請求的具體過程。 檢視日誌檔案並不是一個很好的方法，當微服務越來越多日誌檔案也會越來越多，通過Zipkin可以將日 志聚合，並進行視覺化展示和全文檢索。
關於基於 Zipkin的鏈路追蹤可以檢視下一章：
基於 Zipkin的鏈路追蹤