您現在的位置是:首頁 > 農業
三分鐘帶你搞懂分散式鏈路追蹤系統原理
鏈路追蹤如何不侵入業務
分散式系統為什麼需要鏈路追蹤?
隨著網際網路業務快速擴充套件,軟體架構也日益變得複雜,為了適應海量使用者高併發請求,系統中越來越多的元件開始走向分散式化,如單體架構拆分為微服務、服務內快取變為分散式快取、服務元件通訊變為分散式訊息,這些元件共同構成了繁雜的分散式網路。
假如現在有一個系統部署了成千上萬個服務,使用者透過瀏覽器在主介面上下單一箱茅臺酒,結果系統給使用者提示:系統內部錯誤,相信使用者是很崩潰的。
運營人員將問題拋給開發人員定位,開發人員只知道有異常,但是這個異常具體是由哪個微服務引起的就需要逐個服務排查了。
開發人員藉助日誌逐個排查的效率是非常低的,那有沒有更好的解決方案了?
答案是
引入鏈路追蹤系統
。
什麼是鏈路追蹤?
分散式鏈路追蹤就是將一次分散式請求還原成呼叫鏈路,將一次分散式請求的呼叫情況集中展示,比如各個服務節點上的耗時、請求具體到達哪臺機器上、每個服務節點的請求狀態等等。
鏈路跟蹤主要功能:
故障快速定位
:可以透過呼叫鏈結合業務日誌快速定位錯誤資訊。
鏈路效能視覺化
:各個階段鏈路耗時、服務依賴關係可以透過視覺化介面展現出來。
鏈路分析
:透過分析鏈路耗時、服務依賴關係可以得到使用者的行為路徑,彙總分析應用在很多業務場景。
鏈路追蹤基本原理
鏈路追蹤系統(可能)最早是由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基本實現。
分散式鏈路追蹤系統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介面,運維人員可以根據具體的呼叫鏈資訊快速識別線上問題。
推薦文章
- 不用節食的三種減脂小食,低熱量低脂肪,增強飽腹感
昨天和大家分享了幾道減脂時吃的小食,今天也非常的巧合,下午一位老同學發訊息來問大叔關於健身補劑的問題,又問了一些減脂時該吃什麼樣的食物,大叔與她暢談了一個下午關於健身和減脂的問題,發現她的問題其實也就是很多人在減肥當中的誤區,像我這個同學是...
- 原神:迪希亞技能、天賦曝光,這不開個雙刀就很不禮貌
除了這個天賦圖之外,鴿子還找到一些其他訊息:迪希亞的第二種爆料技能方面描述很少,大家將就看看,首先是E技能,能夠進行火附魔持續時間是10S,不過冷卻可能是15S,有真空期,會將防禦轉化成攻擊和精通,沒有上面描述的清晰,效果也有一些偏差...
- 背光軸帶腕託104鍵設計:DURGOD杜伽GK90電競機械鍵盤體驗
鍵軸設計DURGOD杜伽GK90機械鍵盤的另一個特點是其採用了定製背光軸...