摘要：鏈路追蹤鏈路追蹤一詞是在年提出的，當(dāng)時(shí)谷歌發(fā)布了一篇論文，介紹了谷歌自研的分布式鏈路追蹤的實(shí)現(xiàn)原理，還介紹了他們是怎么低成本實(shí)現(xiàn)對(duì)應(yīng)用透明的。感興趣的同學(xué)可以去深入了解一下鏈路追蹤，希望本文對(duì)你有所幫助。

在微服務(wù)橫行的時(shí)代，服務(wù)化思維逐漸成為了程序員的基本思維模式，但是，由于絕大部分項(xiàng)目只是一味地增加服務(wù)，并沒有對(duì)其妥善管理，當(dāng)接口出現(xiàn)問題時(shí)，很難從錯(cuò)綜復(fù)雜的服務(wù)調(diào)用網(wǎng)絡(luò)中找到問題根源，從而錯(cuò)失了止損的黃金時(shí)機(jī)。

而鏈路追蹤的出現(xiàn)正是為了解決這種問題，它可以在復(fù)雜的服務(wù)調(diào)用中定位問題，還可以在新人加入后臺(tái)團(tuán)隊(duì)之后，讓其清楚地知道自己所負(fù)責(zé)的服務(wù)在哪一環(huán)。

除此之外，如果某個(gè)接口突然耗時(shí)增加，也不必再逐個(gè)服務(wù)查詢耗時(shí)情況，我們可以直觀地分析出服務(wù)的性能瓶頸，方便在流量激增的情況下精準(zhǔn)合理地?cái)U(kuò)容。

“鏈路追蹤”一詞是在2010年提出的，當(dāng)時(shí)谷歌發(fā)布了一篇Dapper論文，介紹了谷歌自研的分布式鏈路追蹤的實(shí)現(xiàn)原理，還介紹了他們是怎么低成本實(shí)現(xiàn)對(duì)應(yīng)用透明的。

其實(shí)Dapper一開始只是一個(gè)獨(dú)立的調(diào)用鏈路追蹤系統(tǒng)，后來逐漸演化成了監(jiān)控平臺(tái)，并且基于監(jiān)控平臺(tái)孕育出了很多工具，比如實(shí)時(shí)預(yù)警、過載保護(hù)、指標(biāo)數(shù)據(jù)查詢等。

除了谷歌的dapper，還有一些其他比較有名的產(chǎn)品，比如阿里的鷹眼、大眾點(diǎn)評(píng)的CAT、Twitter的Zipkin、Naver（著名社交軟件LINE的母公司）的pinpoint以及國產(chǎn)開源的skywalking等。

如果想知道一個(gè)接口在哪個(gè)環(huán)節(jié)出現(xiàn)了問題，就必須清楚該接口調(diào)用了哪些服務(wù)，以及調(diào)用的順序，如果把這些服務(wù)串起來，看起來就像鏈條一樣，我們稱其為調(diào)用鏈。

想要實(shí)現(xiàn)調(diào)用鏈，就要為每次調(diào)用做個(gè)標(biāo)識(shí)，然后將服務(wù)按標(biāo)識(shí)大小排列，可以更清晰地看出調(diào)用順序，我們暫且將該標(biāo)識(shí)命名為spanid。

實(shí)際場景中，我們需要知道某次請求調(diào)用的情況，所以只有spanid還不夠，得為每次請求做個(gè)唯一標(biāo)識(shí)，這樣才能根據(jù)標(biāo)識(shí)查出本次請求調(diào)用的所有服務(wù)，而這個(gè)標(biāo)識(shí)我們命名為traceid。

現(xiàn)在根據(jù)spanid可以輕易地知道被調(diào)用服務(wù)的先后順序，但無法體現(xiàn)調(diào)用的層級(jí)關(guān)系，正如下圖所示，多個(gè)服務(wù)可能是逐級(jí)調(diào)用的鏈條，也可能是同時(shí)被同一個(gè)服務(wù)調(diào)用。

所以應(yīng)該每次都記錄下是誰調(diào)用的，我們用parentid作為這個(gè)標(biāo)識(shí)的名字。

到現(xiàn)在，已經(jīng)知道調(diào)用順序和層級(jí)關(guān)系了，但是接口出現(xiàn)問題后，還是不能找到出問題的環(huán)節(jié)，如果某個(gè)服務(wù)有問題，那個(gè)被調(diào)用執(zhí)行的服務(wù)一定耗時(shí)很長，要想計(jì)算出耗時(shí)，上述的三個(gè)標(biāo)識(shí)還不夠，還需要加上時(shí)間戳，時(shí)間戳可以更精細(xì)一點(diǎn)，精確到微秒級(jí)。

只記錄發(fā)起調(diào)用時(shí)的時(shí)間戳還算不出耗時(shí)，要記錄下服務(wù)返回時(shí)的時(shí)間戳，有始有終才能算出時(shí)間差，既然返回的也記了，就把上述的三個(gè)標(biāo)識(shí)都記一下吧，不然區(qū)分不出是誰的時(shí)間戳。

雖然能計(jì)算出從服務(wù)調(diào)用到服務(wù)返回的總耗時(shí)，但是這個(gè)時(shí)間包含了服務(wù)的執(zhí)行時(shí)間和網(wǎng)絡(luò)延遲，有時(shí)候我們需要區(qū)分出這兩類時(shí)間以方便做針對(duì)性優(yōu)化。那如何計(jì)算網(wǎng)絡(luò)延遲呢？我們可以把調(diào)用和返回的過程分為以下四個(gè)事件。

Client Sent簡稱cs，客戶端發(fā)起調(diào)用請求到服務(wù)端。

Server Received簡稱sr，指服務(wù)端接收到了客戶端的調(diào)用請求。

Server Sent簡稱ss，指服務(wù)端完成了處理，準(zhǔn)備將信息返給客戶端。

Client Received簡稱cr，指客戶端接收到了服務(wù)端的返回信息。

假如在這四個(gè)事件發(fā)生時(shí)記錄下時(shí)間戳，就可以輕松計(jì)算出耗時(shí)，比如sr減去cs就是調(diào)用時(shí)的網(wǎng)絡(luò)延遲，ss減去sr就是服務(wù)執(zhí)行時(shí)間，cr減去ss就是服務(wù)響應(yīng)的延遲，cr減cs就是整個(gè)服務(wù)調(diào)用執(zhí)行的時(shí)間。

其實(shí)span塊內(nèi)除了記錄這幾個(gè)參數(shù)之外，還可以記錄一些其他信息，比如發(fā)起調(diào)用服務(wù)名稱、被調(diào)服務(wù)名稱、返回結(jié)果、IP、調(diào)用服務(wù)的名稱等，最后，我們再把相同spanid的信息合成一個(gè)大的span塊，就完成了一個(gè)完整的調(diào)用鏈。感興趣的同學(xué)可以去深入了解一下鏈路追蹤，希望本文對(duì)你有所幫助。