微服務鏈路追蹤原理

背景介紹

在微服務橫行的時代，服務化思惟逐漸成爲了程序員的基本思惟模式，可是，因爲絕大部分項目只是一味地增長服務，並無對其妥善管理，當接口出現問題時，很難從錯綜複雜的服務調用網絡中找到問題根源，從而錯失了止損的黃金時機。

而鏈路追蹤的出現正是爲了解決這種問題，它能夠在複雜的服務調用中定位問題，還能夠在新人加入後臺團隊以後，讓其清楚地知道本身所負責的服務在哪一環。

除此以外，若是某個接口忽然耗時增長，也沒必要再逐個服務查詢耗時狀況，咱們能夠直觀地分析出服務的性能瓶頸，方便在流量激增的狀況下精準合理地擴容。

鏈路追蹤

「鏈路追蹤」一詞是在2010年提出的，當時谷歌發佈了一篇Dapper論文，介紹了谷歌自研的分佈式鏈路追蹤的實現原理，還介紹了他們是怎麼低成本實現對應用透明的。

其實Dapper一開始只是一個獨立的調用鏈路追蹤系統，後來逐漸演化成了監控平臺，而且基於監控平臺孕育出了不少工具，好比實時預警、過載保護、指標數據查詢等。

除了谷歌的dapper，還有一些其餘比較有名的產品，好比阿里的鷹眼、大衆點評的CAT、Twitter的Zipkin、Naver（著名社交軟件LINE的母公司）的pinpoint以及國產開源的skywalking等。

基本實現原理

若是想知道一個接口在哪一個環節出現了問題，就必須清楚該接口調用了哪些服務，以及調用的順序，若是把這些服務串起來，看起來就像鏈條同樣，咱們稱其爲調用鏈。

想要實現調用鏈，就要爲每次調用作個標識，而後將服務按標識大小排列，能夠更清晰地看出調用順序，咱們暫且將該標識命名爲spanid。

實際場景中，咱們須要知道某次請求調用的狀況，因此只有spanid還不夠，得爲每次請求作個惟一標識，這樣才能根據標識查出本次請求調用的全部服務，而這個標識咱們命名爲traceid。

如今根據spanid能夠輕易地知道被調用服務的前後順序，但沒法體現調用的層級關係，正以下圖所示，多個服務多是逐級調用的鏈條，也多是同時被同一個服務調用。

因此應該每次都記錄下是誰調用的，咱們用parentid做爲這個標識的名字。

到如今，已經知道調用順序和層級關係了，可是接口出現問題後，仍是不能找到出問題的環節，若是某個服務有問題，那個被調用執行的服務必定耗時很長，要想計算出耗時，上述的三個標識還不夠，還須要加上時間戳，時間戳能夠更精細一點，精確到微秒級。

只記錄發起調用時的時間戳還算不出耗時，要記錄下服務返回時的時間戳，善始善終才能算出時間差，既然返回的也記了，就把上述的三個標識都記一下吧，否則區分不出是誰的時間戳。

雖然能計算出從服務調用到服務返回的總耗時，可是這個時間包含了服務的執行時間和網絡延遲，有時候咱們須要區分出這兩類時間以方便作針對性優化。那如何計算網絡延遲呢？咱們能夠把調用和返回的過程分爲如下四個事件。

• Client Sent簡稱cs，客戶端發起調用請求到服務端。
• Server Received簡稱sr，指服務端接收到了客戶端的調用請求。
• Server Sent簡稱ss，指服務端完成了處理，準備將信息返給客戶端。
• Client Received簡稱cr，指客戶端接收到了服務端的返回信息。

假如在這四個事件發生時記錄下時間戳，就能夠輕鬆計算出耗時，好比sr減去cs就是調用時的網絡延遲，ss減去sr就是服務執行時間，cr減去ss就是服務響應的延遲，cr減cs就是整個服務調用執行的時間。

其實span塊內除了記錄這幾個參數以外，還能夠記錄一些其餘信息，好比發起調用服務名稱、被調服務名稱、返回結果、IP、調用服務的名稱等，最後，咱們再把相同spanid的信息合成一個大的span塊，就完成了一個完整的調用鏈。感興趣的同窗能夠去深刻了解一下鏈路追蹤，但願本文對你有所幫助。