SpringCloud：請求鏈路跟蹤sleuth初步認識

為什麼要學習SpringCloud Sleuth

隨著業務的發展，單體架構變為微服務架構，並且系統規模也變得越來越大，各微服務間的

呼叫關係

也變得越來越複雜。在微服務的應用中，一個由客戶端發起的請求在後端系統中會經過多個不同的微服務呼叫來協同產生最後的請求結果，每一個前端請求都會形成一條複雜的分散式服務呼叫鏈路，鏈路中的任何一環出現高延時或錯誤都會引起整個請求最後的失敗。

例如，如下圖所示：在微服務系統中，一個來自使用者的請求，請求先達到前端A（如前端介面）然後透過遠端呼叫，到達系統中介軟體B，C（負載均衡，閘道器等），最後達到後端服務D，E，後端經過一系列的業務邏輯計算最後將資料返回給使用者，對於這樣一個請求，經歷了這麼多個服務，怎麼樣將它的請求過程的資料記錄下來呢？這就需要用到服務鏈路追蹤。

當然，分散式鏈路追蹤技術已然成熟，產品也不少，國內外都有，比如：

Spring Cloud Sleuth + Twitter Zipkin

阿里巴巴的“鷹眼”

大眾點評的“CAT”

美團的“Mtrace”

京東的“Hydra”

新浪的“Watchman”

概述

在微服務架構中，眾多的微服務之間互相呼叫，如何清晰地記錄服務的呼叫鏈路是一個需要解決的問題。同時，由於各種原因，跨程序的服務呼叫失敗時，運維人員希望能夠透過檢視日誌和檢視服務之間的呼叫關係來定位問題，這時就需要解決如何快讀定位服務故障點，以對症下藥，而Spring cloud sleuth元件正是為了解決微服務跟蹤的元件。

一句話總結：sleuth可以解決分散式系統的追蹤問題。

微服務跟蹤解決了什麼問題

微服務跟蹤（sleuth）其實是一個

工具

，它在整個分散式系統中能

跟蹤一個使用者請求的過程

（包括資料採集，資料傳輸，資料儲存，資料分析，資料視覺化），捕獲這些跟蹤資料，就能構建微服務的整個呼叫鏈的檢視，這是除錯和監控微服務的關鍵工具。 Spring Cloud Sleuth有4個特點：

常用術語：Trace

它是由一組有相同Trace ID的Span串聯形成一個樹狀結構。為了實現請求跟蹤，當請求請求到分散式系統的入口端點時，只需要服務跟蹤框架為該請求建立一個唯一的跟蹤標誌，同時在分散式系統內部流轉的時候，框架始終保持傳遞該唯一標誌，直到返回請求為止，我們透過它將所有請求過程中的日誌關聯起來。一句話：

類似於樹結構的Span集合，表示一條呼叫鏈路，存在唯一標誌。

常用術語：Span

它代表了一個基礎的工作單元，例如服務呼叫。為了統計各處理單元的時間延遲，當前請求到達各個服務元件時，也透過一個唯一標誌來標記它的開始、具體過程以及結束。透過span的開始和結束的時間戳，就能統計該span的時間延遲，除此之外，我們還可以獲取如事件名稱、請求資訊等元資料。一句話：

每個trace中會呼叫若干個服務，為了記錄呼叫了哪些服務，以及每次呼叫的消耗時間等資訊，在每次呼叫服務時，埋入一個呼叫記錄。有可以這麼理解：表示呼叫鏈路來源，通俗的理解span就是一次請求資訊。

常用術語：Annotation

它用於記錄一段時間內的事件。內部使用的最重要的術語是：

cs - Client Sent/Start - 客戶端傳送一個請求，這個註解描述了這個Span的開始。

sr - Server Received/Start - 服務端獲得請求並準備開始處理它，其中（sr – cs） 時間戳便可得到網路傳輸的時間。

ss - Server Sent/Finish （服務端傳送響應）– 該註解表明請求處理的完成（當請求返回客戶端）， （ss – sr）時間戳就可以得到伺服器請求的時間。

cr - Client Received/Finished （客戶端接收響應）- 表明此時Span的結束，（cr – cs）時間戳便可以得到整個請求所消耗的時間。

總結圖

好啦，今天的介紹就到這裡了，期待下一期的分享吧