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

不知道身在項(xiàng)目的小伙伴對(duì)上面這樣的對(duì)話熟不熟悉。在項(xiàng)目初期，每次收到QA這樣的詢問，作為開發(fā)的我都覺得很頭大。（因?yàn)橛行┤罩疚沂钦娴恼也坏剑┗跇I(yè)務(wù)的復(fù)雜，項(xiàng)目中接入了大量的外部接口。服務(wù)與服務(wù)鏈路之間的調(diào)用關(guān)系也變得錯(cuò)綜復(fù)雜。此時(shí)，在我們遇上問題排查的時(shí)候，追溯到了某個(gè)接口之后線索就斷了，非常難再往下定位問題。

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

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

這個(gè)時(shí)候，鏈路追蹤能夠幫助我們解決這些實(shí)際問題。

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

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

鏈路追蹤的重要概念：

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

Trace

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

Span

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

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

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

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

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

Annotation

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

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

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

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

Zipkin實(shí)例

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

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

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

同時(shí)由于是首次請(qǐng)求，所以請(qǐng)求中也不會(huì)有parent-span的信息。在圖中也已看到，這個(gè)時(shí)候框架會(huì)給請(qǐng)求生成一個(gè)span信息和trace信息：

由于是初次請(qǐng)求，span id就作為鏈路的trace id：

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

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

小結(jié)

本文介紹鏈路追蹤的關(guān)鍵概念和實(shí)現(xiàn)，讓讀者初步了解鏈路追蹤的作用。實(shí)際上，鏈路追蹤最大的價(jià)值在于“關(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ù)浯髨D。這張拓?fù)鋱D覆蓋的范圍越廣，鏈路追蹤就能發(fā)揮的價(jià)值就越大。全鏈路追蹤是覆蓋全部關(guān)聯(lián) IT 系統(tǒng)的最佳實(shí)踐方案，能夠完整記錄用戶行為在系統(tǒng)間的調(diào)用路徑與狀態(tài)。

文/Thoughtworks 尹中浩
原文鏈接：如何使用鏈路追蹤快速定位問題-Thoughtworks洞見