作者 | 尹中浩

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

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

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

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

“中浩，xxx接口太慢了，你看下是什么原因?qū)е碌摹?/p>

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

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

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

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

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

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

假設(shè)現(xiàn)在有一個如上圖所示的請求，我們應(yīng)該怎樣對這個請求進行記錄呢？

鏈路追蹤的重要概念：

現(xiàn)在市面上絕大部分的鏈路追蹤系統(tǒng)都是以谷歌公開論文中提到的Dapper為基礎(chǔ)構(gòu)建而成，所以我們先來一起看看調(diào)用鏈監(jiān)控中的幾個重要概念。

Trace

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

Span

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

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

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

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

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

Annotation

在上述遇到的問題中，我們除了希望得到整個請求的鏈路。還希望能夠?qū)ζ渲械哪硞€服務(wù)進行調(diào)優(yōu)。這個時候我們就需要對單個服務(wù)，或者說是span，記錄更多的信息。這個時候就需要Annotation的概念了.

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

• Client Start：表示客戶端發(fā)起請求；
• Server Received：表示服務(wù)端收到請求；
• Server Send：表示服務(wù)端完成處理，并將結(jié)果發(fā)送給客戶端；
• Client Received：表示客戶端獲取到服務(wù)端返回的響應(yīng)數(shù)據(jù)。

結(jié)合上圖我們，我們可以利用Annotation里的信息來計算一次調(diào)用的耗時，只需將客戶端結(jié)束的時間點減去客戶端開始請求的時間點。如果要計算客戶端發(fā)送網(wǎng)絡(luò)耗時，即客戶端接收請求的時間點減去客戶端發(fā)送請求的時間點。

Zipkin實例

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

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

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

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

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

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

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

小結(jié)

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