原來10張圖就可以搞懂分布式鏈路追蹤系統(tǒng)原理
分布式系統(tǒng)為什么需要鏈路追蹤?
隨著互聯(lián)網(wǎng)業(yè)務(wù)快速擴(kuò)展,軟件架構(gòu)也日益變得復(fù)雜,為了適應(yīng)海量用戶高并發(fā)請求,系統(tǒng)中越來越多的組件開始走向分布式化,如單體架構(gòu)拆分為微服務(wù)、服務(wù)內(nèi)緩存變?yōu)榉植际骄彺妗⒎?wù)組件通信變?yōu)榉植际较?,這些組件共同構(gòu)成了繁雜的分布式網(wǎng)絡(luò)。
假如現(xiàn)在有一個(gè)系統(tǒng)部署了成千上萬個(gè)服務(wù),用戶通過瀏覽器在主界面上下單一箱茅臺(tái)酒,結(jié)果系統(tǒng)給用戶提示:系統(tǒng)內(nèi)部錯(cuò)誤,相信用戶是很崩潰的。
運(yùn)營人員將問題拋給開發(fā)人員定位,開發(fā)人員只知道有異常,但是這個(gè)異常具體是由哪個(gè)微服務(wù)引起的就需要逐個(gè)服務(wù)排查了。
開發(fā)人員借助日志逐個(gè)排查的效率是非常低的,那有沒有更好的解決方案了?
答案是引入鏈路追蹤系統(tǒng)。
什么是鏈路追蹤?
分布式鏈路追蹤就是將一次分布式請求還原成調(diào)用鏈路,將一次分布式請求的調(diào)用情況集中展示,比如各個(gè)服務(wù)節(jié)點(diǎn)上的耗時(shí)、請求具體到達(dá)哪臺(tái)機(jī)器上、每個(gè)服務(wù)節(jié)點(diǎn)的請求狀態(tài)等等。
鏈路跟蹤主要功能:
-
故障快速定位:可以通過調(diào)用鏈結(jié)合業(yè)務(wù)日志快速定位錯(cuò)誤信息。 -
鏈路性能可視化:各個(gè)階段鏈路耗時(shí)、服務(wù)依賴關(guān)系可以通過可視化界面展現(xiàn)出來。 -
鏈路分析:通過分析鏈路耗時(shí)、服務(wù)依賴關(guān)系可以得到用戶的行為路徑,匯總分析應(yīng)用在很多業(yè)務(wù)場景。
鏈路追蹤基本原理
鏈路追蹤系統(tǒng)(可能)最早是由Goggle公開發(fā)布的一篇論文
《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》
被大家廣泛熟悉,所以各位技術(shù)大牛們?nèi)绻泻谖淦鞑灰仄饋碲s緊去發(fā)表論文吧。
在這篇著名的論文中主要講述了Dapper鏈路追蹤系統(tǒng)的基本原理和關(guān)鍵技術(shù)點(diǎn)。接下來挑幾個(gè)重點(diǎn)的技術(shù)點(diǎn)詳細(xì)給大家介紹一下。
Trace
Trace的含義比較直觀,就是鏈路,指一個(gè)請求經(jīng)過所有服務(wù)的路徑,可以用下面樹狀的圖形表示。
圖中一條完整的鏈路是:chrome -> 服務(wù)A -> 服務(wù)B -> 服務(wù)C -> 服務(wù)D -> 服務(wù)E -> 服務(wù)C -> 服務(wù)A -> chrome。服務(wù)間經(jīng)過的局部鏈路構(gòu)成了一條完整的鏈路,其中每一條局部鏈路都用一個(gè)全局唯一的traceid來標(biāo)識(shí)。
Span
在上圖中可以看出來請求經(jīng)過了服務(wù)A,同時(shí)服務(wù)A又調(diào)用了服務(wù)B和服務(wù)C,但是先調(diào)的服務(wù)B還是服務(wù)C呢?從圖中很難看出來,只有通過查看源碼才知道順序。
為了表達(dá)這種父子關(guān)系引入了Span的概念。
同一層級(jí)parent id相同,span id不同,span id從小到大表示請求的順序,從下圖中可以很明顯看出服務(wù)A是先調(diào)了服務(wù)B然后再調(diào)用了C。
上下層級(jí)代表調(diào)用關(guān)系,如下圖服務(wù)C的span id為2,服務(wù)D的parent id為2,這就表示服務(wù)C和服務(wù)D形成了父子關(guān)系,很明顯是服務(wù)C調(diào)用了服務(wù)D。
總結(jié):通過事先在日志中埋點(diǎn),找出相同traceId的日志,再加上parent id和span id就可以將一條完整的請求調(diào)用鏈串聯(lián)起來。
Annotations
Dapper中還定義了annotation的概念,用于用戶自定義事件,用來輔助定位問題。
通常包含四個(gè)注解信息:
cs:Client Start,表示客戶端發(fā)起請求;
sr:ServerReceived,表示服務(wù)端收到請求;
ss:Server Send,表示服務(wù)端完成處理,并將結(jié)果發(fā)送給客戶端;
cr:ClientReceived,表示客戶端獲取到服務(wù)端返回信息;
上圖中描述了一次請求和響應(yīng)的過程,四個(gè)點(diǎn)也就是對應(yīng)四個(gè)Annotation事件。
如下面的圖表示從客戶端調(diào)用服務(wù)端的一次完整過程。如果要計(jì)算一次調(diào)用的耗時(shí),只需要將客戶端接收的時(shí)間點(diǎn)減去客戶端開始的時(shí)間點(diǎn),也就是圖中時(shí)間線上的T4 - T1。如果要計(jì)算客戶端發(fā)送網(wǎng)絡(luò)耗時(shí),也就是圖中時(shí)間線上的T2 - T1,其他類似可計(jì)算。
帶內(nèi)數(shù)據(jù)與帶外數(shù)據(jù)
鏈路信息的還原依賴于帶內(nèi)和帶外兩種數(shù)據(jù)。
帶外數(shù)據(jù)是各個(gè)節(jié)點(diǎn)產(chǎn)生的事件,如cs,ss,這些數(shù)據(jù)可以由節(jié)點(diǎn)獨(dú)立生成,并且需要集中上報(bào)到存儲(chǔ)端。通過帶外數(shù)據(jù),可以在存儲(chǔ)端分析更多鏈路的細(xì)節(jié)。
帶內(nèi)數(shù)據(jù)如traceid,spanid,parentid,用來標(biāo)識(shí)trace,span,以及span在一個(gè)trace中的位置,這些數(shù)據(jù)需要從鏈路的起點(diǎn)一直傳遞到終點(diǎn)。通過帶內(nèi)數(shù)據(jù)的傳遞,可以將一個(gè)鏈路的所有過程串起來。
采樣
由于每一個(gè)請求都會(huì)生成一個(gè)鏈路,為了減少性能消耗,避免存儲(chǔ)資源的浪費(fèi),dapper并不會(huì)上報(bào)所有的span數(shù)據(jù),而是使用采樣的方式。舉個(gè)例子,每秒有1000個(gè)請求訪問系統(tǒng),如果設(shè)置采樣率為1/1000,那么只會(huì)上報(bào)一個(gè)請求到存儲(chǔ)端。
通過采集端自適應(yīng)地調(diào)整采樣率,控制span上報(bào)的數(shù)量,可以在發(fā)現(xiàn)性能瓶頸的同時(shí),有效減少性能損耗。
存儲(chǔ)
鏈路中的span數(shù)據(jù)經(jīng)過收集和上報(bào)后會(huì)集中存儲(chǔ)在一個(gè)地方,Dapper使用了BigTable數(shù)據(jù)倉庫,常用的存儲(chǔ)還有ElasticSearch, HBase, In-memory DB等。
業(yè)界常用鏈路追蹤系統(tǒng)
Google Dapper論文發(fā)出來之后,很多公司基于鏈路追蹤的基本原理給出了各自的解決方案,如Twitter的Zipkin,Uber的Jaeger,pinpoint,Apache開源的skywalking,還有國產(chǎn)如阿里的鷹眼,美團(tuán)的Mtrace,滴滴Trace,新浪的Watchman,京東的Hydra,不過國內(nèi)的這些基本都沒有開源。
為了便于各系統(tǒng)間能彼此兼容互通,OpenTracing組織制定了一系列標(biāo)準(zhǔn),旨在讓各系統(tǒng)提供統(tǒng)一的接口。
下面對比一下幾個(gè)開源組件,方便日后大家做技術(shù)選型。
附各大開源組件的地址:
-
zipkin? -> https://zipkin.io/ -
Jaeger? -> https://www.jaegertracing.io/ -
Pinpoint? -> https://github.com/pinpoint-apm/pinpoint -
SkyWalking? ->? http://skywalking.apache.org/
接下來介紹一下Zipkin基本實(shí)現(xiàn)。
分布式鏈路追蹤系統(tǒng)Zipkin實(shí)現(xiàn)
Zipkin 是 Twitter 的一個(gè)開源項(xiàng)目,它基于 Google Dapper 實(shí)現(xiàn),它致力于收集服務(wù)的定時(shí)數(shù)據(jù),以解決微服務(wù)架構(gòu)中的延遲問題,包括數(shù)據(jù)的收集、存儲(chǔ)、查找和展現(xiàn)。
Zipkin基本架構(gòu)
在服務(wù)運(yùn)行的過程中會(huì)產(chǎn)生很多鏈路信息,產(chǎn)生數(shù)據(jù)的地方可以稱之為Reporter。將鏈路信息通過多種傳輸方式如HTTP,RPC,kafka消息隊(duì)列等發(fā)送到Zipkin的采集器,Zipkin處理后最終將鏈路信息保存到存儲(chǔ)器中。運(yùn)維人員通過UI界面調(diào)用接口即可查詢調(diào)用鏈信息。
Zipkin核心組件
Zipkin有四大核心組件
(1)Collector
一旦Collector采集線程獲取到鏈路追蹤數(shù)據(jù),Zipkin就會(huì)對其進(jìn)行驗(yàn)證、存儲(chǔ)和索引,并調(diào)用存儲(chǔ)接口保存數(shù)據(jù),以便進(jìn)行查找。
(2)Storage
Zipkin Storage最初是為了在Cassandra上存儲(chǔ)數(shù)據(jù)而構(gòu)建的,因?yàn)镃assandra是可伸縮的,具有靈活的模式,并且在Twitter中大量使用。除了Cassandra,還支持支持ElasticSearch和MySQL存儲(chǔ),后續(xù)可能會(huì)提供第三方擴(kuò)展。
(3)Query Service
鏈路追蹤數(shù)據(jù)被存儲(chǔ)和索引之后,webui 可以調(diào)用query service查詢?nèi)我鈹?shù)據(jù)幫助運(yùn)維人員快速定位線上問題。query service提供了簡單的json api來查找和檢索數(shù)據(jù)。
(4)Web UI
Zipkin 提供了基本查詢、搜索的web界面,運(yùn)維人員可以根據(jù)具體的調(diào)用鏈信息快速識(shí)別線上問題。
總結(jié)
-
分布式鏈路追蹤就是將每一次分布式請求還原成調(diào)用鏈路。 -
鏈路追蹤的核心概念:Trace、Span、Annotation、帶內(nèi)和帶外數(shù)據(jù)、采樣、存儲(chǔ)。 -
業(yè)界常用的開源組件都是基于谷歌Dapper論文演變而來; -
Zipkin核心組件有:Collector、Storage、Query Service、Web UI。
- END -
特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容,還沒關(guān)注的小伙伴,可以長按關(guān)注一下:
長按訂閱更多精彩▼
如有收獲,點(diǎn)個(gè)在看,誠摯感謝
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場,如有問題,請聯(lián)系我們,謝謝!