Sleuth 簡介 隨著業務的發展,系統規模變得越來越大,微服務拆分越來越細,各微服務間的調用關係也越來越複雜。客戶端請求在後端系統中會經過多個不同的微服務調用來協同產生最後的請求結果,幾平每一個請求都會形成一個複雜的分散式服務調用鏈路,在每條鏈路中任何一個依賴服務出現延遲超時或者錯誤都有可能引起整 ...
Sleuth 簡介
隨著業務的發展,系統規模變得越來越大,微服務拆分越來越細,各微服務間的調用關係也越來越複雜。客戶端請求在後端系統中會經過多個不同的微服務調用來協同產生最後的請求結果,幾平每一個請求都會形成一個複雜的分散式服務調用鏈路,在每條鏈路中任何一個依賴服務出現延遲超時或者錯誤都有可能引起整個請求最後的失敗
這時需要一個能夠監控微服務整個調用鏈的工具,跟蹤一個用戶請求的全過程(包括數據採集、數據傳輸、數據存儲、數據分析、數據可視化),捕獲這些跟蹤數據,構建微服務整個調用鏈的視圖,Spring Cloud Sleuth 就是這樣一個工具
服務追蹤系統的實現主要包括三個部分:
- 埋點數據收集:負責在服務端進行埋點,以收集服務調用的上下文數據
- 實時數據處理:負責將收集到的鏈路信息按照 Traccld 和 Spanld 進行串聯和存儲
- 數據鏈路展示:把處理後的服務調用數據按照調用鏈的形式展示出來
下麵我們再來看一下 Sleuth 的核心概念
- Trace:一組 Span 的集合,表示一條調用鏈路,例如,服務 A 調用服務 B,再調用服務 C,A-B-C 鏈路就是一條 Trace,每個服務(例如 B)就是一個Span,如果在服務 B 中再加入兩個線程,分別調用了 D、E,那麼 D、E 就是 B 的子 Span
- TraceId:全局跟蹤 ID,用來標記一次完整服務調用,所以一次服務調用相關的 Span 的 Traceld 都是相同的
- Span:基本工作單元,通過 64 位 ID 唯一標識,Span 還包含其他數據信息,比如摘要、時間藏事件、關鍵值註釋 (tags)、Span 的 ID 以及進度 ID(通常是 IP 地址)
- Id:Span 的 ID,只要做到一個 Traceld 下唯一即可
- Parentld:父 Span 的 ID,調用有層級關係,所以 Span 作為調用節點的存儲結構,也有層級關係
- Annotation:基本標註列表,用來及時記錄一個事件的存在,一個標註可以理解成 Span 生命周期中重要時刻的數據快照,比如一個標註中一般包含發生時刻(timestamp)、事件類型(value)、端點(endpoint)等信息,事件類型包括以下幾種:
- cs(Clien Sent):客戶端發起一個請求,這個 Annotion 註解描述 Span 的開始
- sr(ServerReceived):服務端獲得請求並準備開始處理它,sr 減去 cs 即網路延遲時間
- ss(Server Sent):表明請求處理的完成(請求返回客戶端),ss 減去 sr 即服務端需要的處理請求時間
- cr(Client Received):表明 Span 的結束,客戶端成功接收到服務端的回覆,cr 減去 cs 即客戶端從服務端獲取回覆的所有時間
ZipKin 簡介
Zipkin 是一個開源的分散式追蹤系統,用於對服務間的調用鏈路進行監控追蹤。在微服務架購下,用戶的一個請求可能涉及很多個後臺服務間的調用。Zipkin 可以追蹤(trace)調用鏈路、收集在各個微服務上所花的時間等信息,並上報到 Zipkin 伺服器
Zipkin 提供可插拔數據存儲方式:In-Memory、MySQL、Cassandra 以及 Elasticsearch,為了方便在開發環境直接採用 In-Memory 方式進行存儲,生產數據量大的情況則推薦使用 Elasticsearch
Zipkin 主要由四個核心組件組成:
- Collector:接收或收集各應用傳輸的數據
- Storage:存儲接收或收集過來的數據,當前支持 Memory、MySQL、Cassandra、ElasticSearch 等,預設存儲在記憶體中
- API(Query):負責查詢 Storage 中存儲的數據,提供簡單的 JSON API 獲取數據,主要提供給 Web UI 使用
- UI:官方預設提供的一個圖形用戶界面
Zipkin 以 Trace 結構表示對一次請求的追蹤,把每個 Trace 拆分為若於個有依賴關係的 Span,可以把每個處理請求的服務理解為一個 Span。Zipkin 除了可以查看 Span 的依賴關係之外,還以瀑布圖的形式顯示每個 Span 的耗時情況,可以清晰地看到各個服務的性能狀況。打開每個 Span,還有更詳細的數據以鍵值對的形式呈現,而且這些數據可以在裝備應用的時候自行添加
Zipkin 下載地址:https://repo1.maven.org/maven2/io/zipkin/zipkin-server/
這裡選擇 zipkin-server-2.24.3-exec.jar 版本,既然是一個 jar 包,那麼直接使用 java 命令運行即可,訪問:http://localhost:9411/zipkin/ 可查看控制台
如果使用 MySQL 進行數據存儲,需要事先搭建好 MySQL 資料庫,執行建表腳本,可在 GitHub 獲取:https://github.com/openzipkin/zipkin/blob/master/zipkin-storage/mysql-v1/src/main/resources/mysql.sql
啟動 ZipKin,連接 MySQL,具體啟動命令如下:
java -jar .\zipkin-server-2.24.3-exec.jar --STORAGE_TYPE=mysql --MYSQL_HOST=127.0.0.1 --MYSQL_TCP_PORT=3306 --MYSQL_DB=test_db --MYSQL_USER=root --MYSQL_PASS=123
Spring Cloud Sleuth 整合 ZipKin
在 server-01 和 server-02 項目分別添加依賴
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-sleuth-zipkin</artifactId>
</dependency>
在 server-01 和 server-02 項目分別添加配置
spring:
zipkin:
base-url: http://localhost:9411
enabled: true
sleuth:
enabled: true
如果 spring-cloud-sleuth-zipkin 位於類路徑中,則該應用程式會生成並收集與 Zipkin 相容的 Trace,預設情況下,應用程式通過 HTTP 將 ace 信息發送到本地主機(埠 9411)上的 ZipKin 伺服器,可以通過設置 spring.zipkin.base-url 來配置服務的地址
在 server-01 使用 Feign 調用 server-02 介面
// server-01
@Slf4j
@RestController
public class TestCon {
@Autowired
private Server02FeignClient server02FeignClient;
@GetMapping("/test/getConfigByFeign")
public void getConfigByFeign() {
server02FeignClient.getConfig();
}
}
// server-02
@Slf4j
@RestController
public class TestCon {
@Value("${test.value}")
private String testValue;
@Value("${spring.application.name}")
private String applicationName;
@Value("${server.port}")
private String port;
@GetMapping("/test/getConfig")
public void getConfig() {
log.info("testValue: {} by {}-{}", testValue, applicationName, port);
}
}
查看 ZipKin 控制台,選擇 Dependencies 選項卡,點擊 RUN QUERY 查看具體請求鏈路,選擇 Find a trace 選項卡,單擊 RUN QUERY,可查看具體的請求信息