微服務必備元件Trace-分散式鏈路追蹤(轉發)
原文:
https://blog.csdn.net/dabaoshiwode/article/details/109673681
分散式系統為什麼需要鏈路追蹤?
隨著網際網路業務快速擴充套件,軟體架構也日益變得複雜,為了適應海量使用者高併發請求,系統中越來越多的元件開始走向分散式化,如單體架構拆分為微服務、服務內快取變為分散式快取、服務元件通訊變為分散式訊息,這些元件共同構成了繁雜的分散式網路。
微服務架構(極簡版)
假如現在有一個系統部署了成千上萬個服務,使用者通過瀏覽器在主介面上下單一箱茅臺酒,結果系統給使用者提示:系統內部錯誤,相信使用者是很崩潰的。
運營人員將問題拋給開發人員定位,開發人員只知道有異常,但是這個異常具體是由哪個微服務引起的就需要逐個服務排查了。
介面出現異常難以排查後臺服務
開發人員藉助日誌逐個排查的效率是非常低的,那有沒有更好的解決方案了?
答案是引入鏈路追蹤系統。
什麼是鏈路追蹤?
分散式鏈路追蹤就是將一次分散式請求還原成呼叫鏈路,將一次分散式請求的呼叫情況集中展示,比如各個服務節點上的耗時、請求具體到達哪臺機器上、每個服務節點的請求狀態等等。
鏈路跟蹤主要功能:
-
故障快速定位:可以通過呼叫鏈結合業務日誌快速定位錯誤資訊。
-
鏈路效能視覺化:各個階段鏈路耗時、服務依賴關係可以通過視覺化介面展現出來。
-
鏈路分析:通過分析鏈路耗時、服務依賴關係可以得到使用者的行為路徑,彙總分析應用在很多業務場景。
鏈路追蹤基本原理
鏈路追蹤系統(可能)最早是由Goggle公開發布的一篇論文
《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》
被大家廣泛熟悉,所以各位技術大牛們如果有黑武器不要藏起來趕緊去發表論文吧。
在這篇著名的論文中主要講述了Dapper鏈路追蹤系統的基本原理和關鍵技術點。接下來挑幾個重點的技術點詳細給大家介紹一下。
Trace
Trace的含義比較直觀,就是鏈路,指一個請求經過所有服務的路徑,可以用下面樹狀的圖形表示。
traceId串聯請求形成鏈路
圖中一條完整的鏈路是: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。
Span使請求具有父子關係
總結:通過事先在日誌中埋點,找出相同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基本架構
Zipkin架構
在服務執行的過程中會產生很多鏈路資訊,產生資料的地方可以稱之為Reporter。將鏈路資訊通過多種傳輸方式如HTTP,RPC,kafka訊息佇列等傳送到Zipkin的採集器,Zipkin處理後最終將鏈路資訊儲存到儲存器中。運維人員通過UI介面呼叫介面即可查詢呼叫鏈資訊。
Zipkin核心元件
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。