調用鏈跟蹤基本原理

場景：

開發和運維人員從入口服務A開始查起，確認服務A沒有問題，然後到服務B，在服務B中進行排查，確認服務B沒有問題，在傳遞到服務C中進行排查，以此類推。有時查一個問題，會把服務架構中的多個應用查詢一遍，而有時出問題的系統恰恰是底層系統，在排查了多個不必要的系統後才能準確的定位問題。
如何解決該問題呢？那就是服務調用鏈路跟蹤

調用鏈路跟蹤

谷歌在2010年發佈的Dapper論文中介紹了谷歌分佈式系統跟蹤的基礎原理和架構，介紹了谷歌以低成本實現應用級透明的遍佈多個服務的調用鏈跟蹤系統的方法。
Dapper開始僅僅是一個獨立的調用鏈路跟蹤系統，後來逐步演化爲一個監控平臺，並且在監控平臺上孕育了許多工具。
典型的分佈式系統的調用關係圖：

服務調用結構是一個樹型結構，樹節點是整個架構的基本單元，每個節點是一個獨立的服務節點。在谷歌的Dapper論文中，每個節點都對應一個Span，節點之間的連線表示Span和它的父Span之間的關係，具體表現爲一次調用請求和響應的調用關係。
我們先關注兩個服務之間的同學，兩個服務之間有成千上萬次通信，服務1與服務2進行交互時，會發送一個請求1，並接收到一個響應1，那麼我們通過什麼手段標示響應和請求是一對呢？

谷歌的Dapper論文通過增加應用層的標記對服務化中的請求和響應建立聯繫，例如通過HTTP協議頭攜帶標記信息，標記信息包括標示調用鏈的唯一ID，這裏叫作TraceID，以及標示調用層次和順序的SpanID和ParentSpanID。
下面是一次調用需要保存的調用信息：

調用信息包含：調用端或者被調用端的ID、系統ID；本次請求的TraceID、SpanID和ParentSpanID；時間戳、調用的方法名稱及遠程調用信息的類型，等等。

TraceID

前端接收用戶請求後會爲用戶分配一個TraceID，在內部服務調用時，會通過應用層的協議將TraceID傳遞到下層服務，直到整個調用鏈的每個節點都擁有TraceID，這樣在系統出現問題時，可以使用這個唯一TraceID迅速問題發生的節點。

SpanID

TraceID解決了系統串聯的問題，但是我們無法標識和恢復這些請求和響應調用時的順序和層級關係.
因此我們需要附加的信息在系統之間的請求和響應消息中傳遞，它就是SpanID，這裏SpanID包含SpanID和ParentSpanID
SpanID和ParentSpanID組合在一起就可以表示一個樹形的調用關係，SpanID表示當前爲一個調用節點，ParentSpanID表示這個調用節點的父節點。
以下通過時序的角度來看下SpanID和ParentSpanID在調用鏈中攜帶的信息和含義：

當系統出現故障時，只需4步即可：

• （1）通過TraceID把一整條調用鏈的所有調用信息收集到一個集合中，包括請求和響應
• （2）通過SpanID和ParentSpanID恢復樹形的調用樹，ParentSpanID爲-1的節點爲根節點
• （3）識別調用鏈中出錯或超時的節點，做出標記
• （4）把恢復的調用樹和出錯的節點信息通過某種圖形顯示到UI界面上。

有多種策略產生SpanID

• （1）使用隨機數產生SpanID，理論上有可能重複，但是由於64位長整型，重複的可能性微乎其微，並且本地生成隨機數的效率高於其他方法。
• （2）使用分佈式的全局唯一的流水號生成方式，可參考互聯網發好器Vesta。
• （3）每個SpanID包含所有父親及前輩節點的SpanID，使用圓點符號作爲分隔符，不再需要ParentSpanID字段，如下圖，這種方案實現起來簡單，但是如果調用鏈有太多的節點和層次時，SpanID會攜帶太多的冗餘信息，導致服務間調用的性能下降。
  

業務鏈

在實踐中，由於業務流程的複雜性，一個業務流程的完成由用戶的多次請求組成，這些請求之間是有關聯的，我們在串聯調用鏈滯後，會根據業務的數學，將不同的調用鏈聚合在一起形成業務鏈。
我們需要在多次請求之間建立聯繫，可以通過業務的業務ID(如：訂單ID)來串聯業務鏈，如果調用鏈是一個簡單的樹形結構，而業務鏈就是一個森林結構：