在微服務橫行的時代，服務化思維逐漸成為了程式員的基本思維模式，但是，由于絕大部分項目隻是一味地增加服務，并沒有對其妥善管理，當接口出現問題時，很難從錯綜複雜的服務調用網絡中找到問題根源，進而錯失了止損的黃金時機。
而鍊路追蹤的出現正是為了解決這種問題，它可以在複雜的服務調用中定位問題，還可以在新人加入背景團隊之後，讓其清楚地知道自己所負責的服務在哪一環。
除此之外，如果某個接口突然耗時增加，也不必再逐個服務查詢耗時情況，我們可以直覺地分析出服務的性能瓶頸，友善在流量激增的情況下精準合理地擴容。
“鍊路追蹤”一詞是在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塊，就完成了一個完整的調用鍊。感興趣的同學可以去深入了解一下鍊路追蹤，希望本文對你有所幫助。