作者 | 尹中浩

“中浩，xxx接口報錯了你看一下咋回事”

“稍等一下哈，我看一下。Xxx組的xxx接口報錯了,我們這邊直接拋錯了”

“具體啥問題啊，你看下日志，我去找xxx組的人問一下，現在阻塞流程了啊”

“呃。。。對這個接口的請求日志好難找啊，這個接口請求很頻繁，不知道報錯的是哪一條。。”

“中浩，xxx接口太慢了，你看下是什么原因導致的”

“這個接口我們掉了很多外部接口啊，不知道具體是哪個接口太慢了”

不知道身在項目的小伙伴對上面這樣的對話熟不熟悉。在項目初期，每次收到QA這樣的詢問，作為開發的我都覺得很頭大。（因為有些日志我是真的找不到）基于業務的復雜，項目中接入了大量的外部接口。服務與服務鏈路之間的調用關系也變得錯綜復雜。此時，在我們遇上問題排查的時候，追溯到了某個接口之后線索就斷了，非常難再往下定位問題。

此時我們自然而然地就會想：難道就沒有一種方法能夠把請求的整個調用鏈路記錄下來，并通過某個唯一id標記，同時對每個節點都進行記錄嘛？這樣我們就能通過標記在請求鏈路上的這個唯一id來快速定位問題，從而大量節省我們排查問題和統計分析的時間。其實上述的只是我們在微服務中最常遇上的兩個問題。隨著微服務應用數量的極速增加，服務與服務鏈路之間的調用關系也變得錯綜復雜。此時，我們也會碰到其他各種難題。

• 系統出現問題后，由于服務鏈路過長或過于復雜，無法快速準確定位問題。客戶端（如瀏覽器）或者移動端應用報出異常或者錯誤，也無法確定是哪個服務拋出的異常。
• 某個業務請求非常慢，且總是超時，無法確定系統哪個環節存在性能的問題。
• 修改成：如何快速發現問題并可以通過調用鏈結合業務日志快速定位錯誤信息？
• 如何判斷故障影響范圍，并將各個階段鏈路耗時、服務依賴關系可以通過可視化界面展現出來，從而直觀地審視故障的影響范圍？
• 如何梳理服務依賴以及依賴的合理性？如何分析鏈路性能問題以及實時容量規劃？通過分析鏈路耗時、服務間的依賴關系，就可以得到用戶的行為路徑，匯總分析出具體出問題的場景。

這個時候，鏈路追蹤能夠幫助我們解決這些實際問題。

圖片來源：《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》 -- Google Technical Report dapper-2010-1, April 2010

假設現在有一個如上圖所示的請求，我們應該怎樣對這個請求進行記錄呢？

鏈路追蹤的重要概念：

現在市面上絕大部分的鏈路追蹤系統都是以谷歌公開論文中提到的Dapper為基礎構建而成，所以我們先來一起看看調用鏈監控中的幾個重要概念。

Trace

在之前的描述中我們已經想到，能不能通過一個唯一id來標記我們的請求，從而將整個請求從頭到尾串聯起來。在鏈路追蹤中，trace是請求在分布式系統中的整個鏈路視圖。我們可以把trace看作一棵二叉樹，從中我們能直觀地看到請求經過所有服務的路徑。從請求到服務器開始，到服務器返回響應數據結束，跟蹤每次RPC調用的耗時，并使用唯一標識trace id。在整個請求的調用鏈中，請求會一直攜帶 trace id 往下游服務傳遞，且在整個調用鏈中始終保持不變，所以在日志中可以通過 trace id 查詢到整個請求期間系統記錄下來的所有日志。

Span

在建立了一個完整的標識之后，我們還希望對每個節點都進行記錄。不然我們只知道一個請求調用了那些服務，但是卻不清楚各個服務之間的上下游以及調用關系。span 是代表整個鏈路中不同服務內部的視圖。如果我們將trace看作 一棵樹的話，那么span就是這棵樹上的不同節點。

每個 span 都記錄著 parent id 和 trace id，表明其所屬父節點和調用鏈，其中沒有 parent id 的 span 稱為 root span，root span 的 id 就是 trace id。請求到達每個服務后，服務都會為請求生成span id，而隨請求一起從上游傳過來的上游服務的 span id 會被記錄成parent-span id。

當前服務生成的 span id 隨著請求一起再傳到下游服務時，這個span id 又會被下游服務當做 parent-span id記錄。通過span的ID我們可以輕松了解服務的父服務是誰，再結合trace id就可以將一條完整的請求調用鏈串聯起來。

圖片來源：《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》 -- Google Technical Report dapper-2010-1, April 2010

針對以上請求，整個調用的鏈路就如圖所示非常清晰了。

Annotation

在上述遇到的問題中，我們除了希望得到整個請求的鏈路。還希望能夠對其中的某個服務進行調優。這個時候我們就需要對單個服務，或者說是span，記錄更多的信息。這個時候就需要Annotation的概念了.

圖片來源：《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》 -- Google Technical Report dapper-2010-1, April 2010

• Client Start：表示客戶端發起請求；
• Server Received：表示服務端收到請求；
• Server Send：表示服務端完成處理，并將結果發送給客戶端；
• Client Received：表示客戶端獲取到服務端返回的響應數據。

結合上圖我們，我們可以利用Annotation里的信息來計算一次調用的耗時，只需將客戶端結束的時間點減去客戶端開始請求的時間點。如果要計算客戶端發送網絡耗時，即客戶端接收請求的時間點減去客戶端發送請求的時間點。

Zipkin實例

遵循以上三點鏈路追蹤的核心思路，我們來看一看現在市面上主流的鏈路追蹤款框架都是怎么實現的，這里我們以Zipkin為例。

可以看到，我們的請求到達服務器之后被攔截下來：

在這個filter中，框架首先會查詢我們請求（request）是否存在鏈路信息。圖中可以看到，我們的初次請求是沒有trace的內容的：

同時由于是首次請求，所以請求中也不會有parent-span的信息。在圖中也已看到，這個時候框架會給請求生成一個span信息和trace信息：

由于是初次請求，span id就作為鏈路的trace id：

最后框架將生成的span信息和trace信息，設置到我們請求的attribute當中并傳遞下去：

通過我們的代碼，我們能夠很清晰的看到zipkin是如何給我們的請求加上trace信息和span信息，并將其傳遞下去的。此時我們就能夠通過trace中的trace id，快速地發現和定位問題。

小結

本文介紹鏈路追蹤的關鍵概念和實現，讓讀者初步了解鏈路追蹤的作用。實際上，鏈路追蹤最大的價值在于“關聯”。我們可以從數據層面關聯應用日志（Logs）、關鍵事件（Events）、性能指標（Metrics）或診斷工具（Profiling），也可以從系統層面關聯用戶終端、網關、應用、中間件、容器與基礎設施。通過鏈路追蹤，我們可以構建一張軌跡拓撲大圖。這張拓撲圖覆蓋的范圍越廣，鏈路追蹤就能發揮的價值就越大。全鏈路追蹤是覆蓋全部關聯 IT 系統的最佳實踐方案，能夠完整記錄用戶行為在系統間的調用路徑與狀態。