微服務鏈路追蹤原理

背景介紹

在微服務橫行的時代,服務化思維逐漸成為了程序員的基本思維模式,但是,由于絕大部分項目只是一味地增加服務,并沒有對其妥善管理,當接口出現問題時,很難從錯綜復雜的服務調用網絡中找到問題根源,從而錯失了止損的黃金時機。

而鏈路追蹤的出現正是為了解決這種問題,它可以在復雜的服務調用中定位問題,還可以在新人加入后臺團隊之后,讓其清楚地知道自己所負責的服務在哪一環。

除此之外,如果某個接口突然耗時增加,也不必再逐個服務查詢耗時情況,我們可以直觀地分析出服務的性能瓶頸,方便在流量激增的情況下精準合理地擴容。

鏈路追蹤

“鏈路追蹤”一詞是在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塊,就完成了一個完整的調用鏈。感興趣的同學可以去深入了解一下鏈路追蹤,希望本文對你有所幫助。

posted @ 2019-06-07 00:56 張大帥z 閱讀(...) 評論(...) 編輯 收藏