本文github/SmileLionCoder已收錄，有Java程式設計師進階技術知識地圖以及我的系列文章，歡迎大家Star。

分散式系統為什麼需要鏈路追蹤？

隨著網際網路業務快速擴充套件，軟體架構也日益變得複雜，為了適應海量使用者高併發請求，系統中越來越多的元件開始走向分散式化，如單體架構拆分為微服務、服務內快取變為分散式快取、服務元件通訊變為分散式訊息，這些元件共同構成了繁雜的分散式網路。

假如現在有一個系統部署了成千上萬個服務，使用者透過瀏覽器在主介面上下單一箱茅臺酒，結果系統給使用者提示：系統內部錯誤，相信使用者是很崩潰的。

運營人員將問題拋給開發人員定位，開發人員只知道有異常，但是這個異常具體是由哪個微服務引起的就需要逐個服務排查了。

開發人員藉助日誌逐個排查的效率是非常低的，那有沒有更好的解決方案了？

答案是引入鏈路追蹤系統。

什麼是鏈路追蹤？

分散式鏈路追蹤就是將一次分散式請求還原成呼叫鏈路，將一次分散式請求的呼叫情況集中展示，比如各個服務節點上的耗時、請求具體到達哪臺機器上、每個服務節點的請求狀態等等。

鏈路跟蹤主要功能：

故障快速定位

：可以透過呼叫鏈結合業務日誌快速定位錯誤資訊。

鏈路效能視覺化

：各個階段鏈路耗時、服務依賴關係可以透過視覺化介面展現出來。

鏈路分析

：透過分析鏈路耗時、服務依賴關係可以得到使用者的行為路徑，彙總分析應用在很多業務場景。

鏈路追蹤基本原理

鏈路追蹤系統（可能）最早是由Goggle公開發布的一篇論文《Dapper， a Large-Scale Distributed Systems Tracing Infrastructure》被大家廣泛熟悉，所以各位技術大牛們如果有黑武器不要藏起來趕緊去發表論文吧。

在這篇著名的論文中主要講述了Dapper鏈路追蹤系統的基本原理和關鍵技術點。接下來挑幾個重點的技術點詳細給大家介紹一下。

Trace

Trace的含義比較直觀，就是鏈路，指一個請求經過所有服務的路徑，可以用下面樹狀的圖形表示。

圖中一條完整的鏈路是：chrome -> 服務A -> 服務B -> 服務C -> 服務D -> 服務E -> 服務C -> 服務A -> chrome。服務間經過的區域性鏈路構成了一條完整的鏈路，其中每一條區域性鏈路都用一個全域性唯一的traceid來標識。

Span

在上圖中可以看出來請求經過了服務A，同時服務A又呼叫了服務B和服務C，但是先調的服務B還是服務C呢？從圖中很難看出來，只有透過檢視原始碼才知道順序。

為了表達這種父子關係引入了Span的概念。

同一層級parent id相同，span id不同，span id從小到大表示請求的順序，從下圖中可以很明顯看出服務A是先調了服務B然後再呼叫了C。

上下層級代表呼叫關係，如下圖服務C的span id為2，服務D的parent id為2，這就表示服務C和服務D形成了父子關係，很明顯是服務C呼叫了服務D。

總結：透過事先在日誌中埋點，找出相同traceId的日誌，再加上parent id和span id就可以將一條完整的請求呼叫鏈串聯起來。

Annotations

Dapper中還定義了annotation的概念，用於使用者自定義事件，用來輔助定位問題。

通常包含四個註解資訊

： cs：Client Start，表示客戶端發起請求； sr：ServerReceived，表示服務端收到請求； ss： Server Send，表示服務端完成處理，並將結果傳送給客戶端； cr：ClientReceived，表示客戶端獲取到服務端返回資訊；

上圖中描述了一次請求和響應的過程，四個點也就是對應四個Annotation事件。

如下面的圖表示從客戶端呼叫服務端的一次完整過程。如果要計算一次呼叫的耗時，只需要將客戶端接收的時間點減去客戶端開始的時間點，也就是圖中時間線上的T4 - T1。如果要計算客戶端傳送網路耗時，也就是圖中時間線上的T2 - T1，其他類似可計算。

帶內資料與帶外資料

鏈路資訊的還原依賴於

帶內

和

帶外

兩種資料。

帶外資料是各個節點產生的事件，如cs，ss，這些資料可以由節點獨立生成，並且需要集中上報到儲存端。透過帶外資料，可以在儲存端分析更多鏈路的細節。

帶內資料如traceid，spanid，parentid，用來標識trace，span，以及span在一個trace中的位置，這些資料需要從鏈路的起點一直傳遞到終點。 透過帶內資料的傳遞，可以將一個鏈路的所有過程串起來。

取樣

由於每一個請求都會生成一個鏈路，為了減少效能消耗，避免儲存資源的浪費，dapper並不會上報所有的span資料，而是使用取樣的方式。舉個例子，每秒有1000個請求訪問系統，如果設定取樣率為1/1000，那麼只會上報一個請求到儲存端。

透過採集端自適應地調整取樣率，控制span上報的數量，可以在發現效能瓶頸的同時，有效減少效能損耗。

儲存

鏈路中的span資料經過收集和上報後會集中儲存在一個地方，Dapper使用了BigTable資料倉庫，常用的儲存還有ElasticSearch， HBase， In-memory DB等。

業界常用鏈路追蹤系統

Google Dapper論文發出來之後，很多公司基於鏈路追蹤的基本原理給出了各自的解決方案，如Twitter的Zipkin，Uber的Jaeger，pinpoint，Apache開源的skywalking，還有國產如阿里的鷹眼，美團的Mtrace，滴滴Trace，新浪的Watchman，京東的Hydra，不過國內的這些基本都沒有開源。

為了便於各系統間能彼此相容互通，OpenTracing組織制定了一系列標準，旨在讓各系統提供統一的介面。

下面對比一下幾個開源元件，方便日後大家做技術選型。

附各大開源元件的地址：

zipkin

https://zipkin.io/

Jaeger

www.jaegertracing.io/

Pinpoint

https://github.com/pinpoint-apm/pinpoint

SkyWalking

http://skywalking.apache.org/

接下來介紹一下Zipkin基本實現。

分散式鏈路追蹤系統Zipkin實現

Zipkin 是 Twitter 的一個開源專案，它基於 Google Dapper 實現，它致力於收集服務的定時資料，以解決微服務架構中的延遲問題，包括資料的收集、儲存、查詢和展現。

Zipkin基本架構

在服務執行的過程中會產生很多鏈路資訊，產生資料的地方可以稱之為Reporter。將鏈路資訊透過多種傳輸方式如HTTP，RPC，kafka訊息佇列等傳送到Zipkin的採集器，Zipkin處理後最終將鏈路資訊儲存到儲存器中。運維人員透過UI介面呼叫介面即可查詢呼叫鏈資訊。

Zipkin核心元件

Zipkin有四大核心元件

（1）Collector

一旦Collector採集執行緒獲取到鏈路追蹤資料，Zipkin就會對其進行驗證、儲存和索引，並呼叫儲存介面儲存資料，以便進行查詢。

（2）Storage

Zipkin Storage最初是為了在Cassandra上儲存資料而構建的，因為Cassandra是可伸縮的，具有靈活的模式，並且在Twitter中大量使用。除了Cassandra，還支援支援ElasticSearch和MySQL儲存，後續可能會提供第三方擴充套件。

（3）Query Service

鏈路追蹤資料被儲存和索引之後，webui 可以呼叫query service查詢任意資料幫助運維人員快速定位線上問題。query service提供了簡單的json api來查詢和檢索資料。

（4）Web UI

Zipkin 提供了基本查詢、搜尋的web介面，運維人員可以根據具體的呼叫鏈資訊快速識別線上問題。

總結

分散式鏈路追蹤就是將每一次分散式請求還原成呼叫鏈路。

鏈路追蹤的核心概念：Trace、Span、Annotation、帶內和帶外資料、取樣、儲存。

業界常用的開源元件都是基於谷歌Dapper論文演變而來；

Zipkin核心元件有：Collector、Storage、Query Service、Web UI。

—— END ——

大家好，你可以叫我“雷架”。

讀過幾年書：華中科技大學碩士畢業；

浪過幾個大廠：華為、網易、百度……

一直堅信技術能改變生活，願保持初心，加油技術人！

文章持續更新，在 github/SmileLionCoder中可以看到我歸檔的系列文章，有面試經驗和技術乾貨，歡迎Star。