分布式系統為什么需要鏈路追蹤？

隨著互聯網業務快速擴展，軟件架構也日益變得復雜，為了適應海量用戶高并發請求，系統中越來越多的組件開始走向分布式化，如單體架構拆分為微服務、服務內緩存變為分布式緩存、服務組件通信變為分布式消息，這些組件共同構成了繁雜的分布式網絡。

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

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

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

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

什么是鏈路追蹤？

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

鏈路跟蹤主要功能：

• 故障快速定位：可以通過調用鏈結合業務日志快速定位錯誤信息。
• 鏈路性能可視化：各個階段鏈路耗時、服務依賴關系可以通過可視化界面展現出來。
• 鏈路分析：通過分析鏈路耗時、服務依賴關系可以得到用戶的行為路徑，匯總分析應用在很多業務場景。

鏈路追蹤基本原理

鏈路追蹤系統（可能）最早是由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 -> https://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界面，運維人員可以根據具體的調用鏈信息快速識別線上問題。

總結

1. 分布式鏈路追蹤就是將每一次分布式請求還原成調用鏈路。
2. 鏈路追蹤的核心概念：Trace、Span、Annotation、帶內和帶外數據、采樣、存儲。
3. 業界常用的開源組件都是基于谷歌Dapper論文演變而來；
4. Zipkin核心組件有：Collector、Storage、Query Service、Web UI。

為什么阿里巴巴的程序員成長速度這么快？

霸榜GitHub的Offer來了原理篇＋框架篇，開放分享；

50W年薪程序員需要的技術棧分析

看完三件事??

如果你覺得這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：

點贊，轉發，有你們的 『點贊和評論』，才是我創造的動力。

關注公眾號 『 Java斗帝 』，不定期分享原創知識。

同時可以期待后續文章ing??