路追蹤:核心原理與解決方案
本章概述
隨著網際網路的不斷髮展,企業的業務系統變得越來越複雜,原本單一的單體應用系統已經無法滿足企業業務發展的需要。於是,很多企業開始了對專案的分散式與微服務改造,新專案也在開始的時候就會採用分散式與微服務的架構模式。
一個系統採用分散式與微服務架構後,會被拆分成許多服務模組,這些服務模組之間的呼叫關係錯綜複雜,對於客戶端請求的分析與處理就會顯得異常複雜。此時,就需要一種技術來解決這些問題,而這種技術就是分散式鏈路追蹤技術。
分散式鏈路追蹤
隨著網際網路業務快速擴充套件,企業的業務系統變得越來越複雜,不少企業開始向分散式、微服務方向發展,將原本的單體應用拆分成分散式、微服務。這也使得當客戶端請求系統的介面時,原本在同一個系統內部的請求邏輯變成了需要在多個微服務之間流轉的請求。
單體架構中可以使用AOP在呼叫具體的業務邏輯前後分別列印一下時間即可計算出整體的呼叫時間,使用 AOP捕獲異常也可知道是哪裡的呼叫導致的異常。
但是在分散式微服務場景下,使用AOP技術是無法追蹤到各個微服務的呼叫情況的,也就無法知道系統中處理一次請求的整體呼叫鏈路。
另外,在分散式與微服務場景下,我們需要解決如下問題:
- 如何快速發現並定位到分散式系統中的問題。
- 如何儘可能精確的判斷故障對系統的影響範圍與影響程度。
- 如何儘可能精確的梳理出服務之間的依賴關係,並判斷出服務之間的依賴關係是否合理。
- 如何儘可能精確的分析整個系統呼叫鏈路的效能與瓶頸點。
- 如何儘可能精確的分析系統的儲存瓶頸與容量規劃。
- 如何實時觀測系統的整體呼叫鏈路情況。
上述問題就是分散式鏈路追蹤技術要解決的問題。所謂的分散式鏈路追蹤,就是將對分散式系統的一次請求轉化成一個完整的呼叫鏈路。這個完整的呼叫鏈路從請求進入分散式系統的入口開始,直到整個請求返回為止。並在請求呼叫微服務的過程中,記錄相應的呼叫日誌,監控系統呼叫的效能,並且可以按照某種方式顯示請求呼叫的情況。
在分散式鏈路追蹤中,可以統計呼叫每個微服務的耗時,請求會經過哪些微服務的流轉,每個微服務的執行狀況等資訊。
核心原理
假定三個微服務呼叫的鏈路如下圖所示:Service 1 呼叫 Service 2,Service 2 呼叫 Service 3 和 Service 4。
那麼鏈路追蹤會在每個服務呼叫的時候加上 Trace ID 和 Span ID。如下圖所示:
小夥伴注意上面的顏色,相同顏色的代表是同一個 Span ID,說明是鏈路追蹤中的一個節點。
- 第一步:使用者端呼叫 Service 1,生成一個 Request,Trace ID 和 Span ID 為空,那個時候請求還沒有到 Service 1。
- 第二步:請求到達 Service 1,記錄了 Trace ID = X,Span ID 等於 A。
- 第三步:Service 1 傳送請求給 Service 2,Span ID 等於 B,被稱作 Client Sent,即使用者端傳送一個請求。
- 第四步:請求到達 Service 2,Span ID 等於 B,Trace ID 不會改變,被稱作 Server Received,即服務端取得請求並準備開始解決它。
- 第五步:Service 2 開始解決這個請求,解決完之後,Trace ID 不變,Span ID = C。
- 第六步:Service 2 開始傳送這個請求給 Service 3,Trace ID 不變,Span ID = D,被稱作 Client Sent,即使用者端傳送一個請求。
- 第七步:Service 3 接收到這個請求,Span ID = D,被稱作 Server Received。
- 第八步:Service 3 開始解決這個請求,解決完之後,Span ID = E。
- 第九步:Service 3 開始傳送響應給 Service 2,Span ID = D,被稱作 Server Sent,即服務端傳送響應。
- 第十步:Service 3 收到 Service 2 的響應,Span ID = D,被稱作 Client Received,即使用者端接收響應。
- 第十一步:Service 2 開始返回 響應給 Service 1,Span ID = B,和第三步的 Span ID 相同,被稱作 Client Received,即使用者端接收響應。
- 第十二步:Service 1 解決完響應,Span ID = A,和第二步的 Span ID 相同。
- 第十三步:Service 1 開始向用戶端返回響應,Span ID = A、
- Service 3 向 Service 4 傳送請求和 Service 3 相似,對應的 Span ID 是 F 和 G。可以參照上面前面的第六步到第十步。
把以上的相同顏色的步驟簡化為下面的鏈路追蹤圖:
- 第一個節點:Span ID = A,Parent ID = null,Service 1 接收到請求。
- 第二個節點:Span ID = B,Parent ID= A,Service 1 傳送請求到 Service 2 返回響應給Service 1 的過程。
- 第三個節點:Span ID = C,Parent ID= B,Service 2 的 中間解決過程。
- 第四個節點:Span ID = D,Parent ID= C,Service 2 傳送請求到 Service 3 返回響應給Service 2 的過程。
- 第五個節點:Span ID = E,Parent ID= D,Service 3 的中間解決過程。
- 第六個節點:Span ID = F,Parent ID= C,Service 3 傳送請求到 Service 4 返回響應給 Service 3 的過程。
- 第七個節點:Span ID = G,Parent ID= F,Service 4 的中間解決過程。
通過 Parent ID 就可找到父節點,整個鏈路即可以進行跟蹤追溯了。
備註:核心原理部分內容來源:cnblogs.com/jackson0714/p/sleuth_zipkin.html
解決方案
目前,行業內比較成熟的分散式鏈路追蹤技術解決方案如下所示。
技術 |
說明 |
Cat |
由大眾點評開源,基於Java開發的實時應用監控平臺,包括實時應用監控,業務監控 。整合方案是通過程式碼埋點的方式來實現監控,比如:攔截器,過濾器等。對程式碼的侵入性很大,整合成本較高。風險較大。 |
ZipKin |
由Twitter公司開源,開放原始碼分散式的跟蹤系統,用於收集服務的定時資料,以解決微服務架構中的延遲問題,包括:資料的收集、儲存、查詢和展現。結合spring-cloud-sleuth使用較為簡單, 整合方便, 但是功能較簡單。 |
Pinpoint |
Pinpoint是一款開源的基於位元組碼注入的呼叫鏈分析,以及應用監控分析工具。特點是支援多種外掛, UI功能強大,接入端無程式碼侵入。 |
Skywalking |
SkyWalking是國人開源的基於位元組碼注入的呼叫鏈分析,以及應用監控分析工具。特點是支援多種外掛, UI功能較強,接入端無程式碼侵入。 |
Sleuth |
Sleuth是SpringCloud中的一個元件,為Spring Cloud實現了分散式跟蹤解決方案。 |
- 介紹一款進階版的 Pandas 資料分析神器:Polars
- Python包管理工具之Pipenv
- 聊聊 Vue 的雙端 Diff 演算法
- 「Spring」Boot Docker 認證指南(上)
- 2022 年會是您採用多雲的一年嗎?
- Spring MVC中@InitBinder註解是如何應用的?
- 5分鐘的時間製作一個反彈球遊戲
- 使用 Python 的 requests 和 Beautiful Soup 來分析網頁
- 監控Kubernetes的最佳實踐、工具和方法
- 基於Electron開發Hosts切換工具的“踩坑”之旅
- Pandas 新手容易犯的六個錯誤
- 2022 年需求中優秀的 DevOps 工具
- 一日一技:如何實現帶Timeout的Input?
- 13 個非常有用的 Python 程式碼片段,建議收藏!
- [科普文] 淺談 Function Programing 程式設計正規化
- 什麼是Pulsar函式流處理應用?
- Flask vs Django: 該如何選擇Python框架?
- 如何最大限度提升智慧建築中的網路安全?
- 為什麼智慧建築IoT網路安全標準很重要?
- 做大做強雲端計算市場須立足實際