分布式系統(tǒng)為什么需要鏈路追蹤？

隨著互聯(lián)網(wǎng)業(yè)務(wù)快速擴(kuò)展，圖可統(tǒng)原軟件架構(gòu)也日益變得復(fù)雜，搞懂為了適應(yīng)海量用戶高并發(fā)請(qǐng)求，分布系統(tǒng)中越來(lái)越多的式鏈組件開(kāi)始走向分布式化，如單體架構(gòu)拆分為微服務(wù)、追理服務(wù)內(nèi)緩存變?yōu)榉植际骄彺?、蹤系服?wù)組件通信變?yōu)榉植际较?，原張這些組件共同構(gòu)成了繁雜的分布式網(wǎng)絡(luò)。

假如現(xiàn)在有一個(gè)系統(tǒng)部署了成千上萬(wàn)個(gè)服務(wù)，用戶通過(guò)瀏覽器在主界面上下單一箱茅臺(tái)酒，結(jié)果系統(tǒng)給用戶提示：系統(tǒng)內(nèi)部錯(cuò)誤，相信用戶是很崩潰的。

運(yùn)營(yíng)人員將問(wèn)題拋給開(kāi)發(fā)人員定位，開(kāi)發(fā)人員只知道有異常，但是這個(gè)異常具體是由哪個(gè)微服務(wù)引起的就需要逐個(gè)服務(wù)排查了。

開(kāi)發(fā)人員借助日志逐個(gè)排查的效率是非常低的，那有沒(méi)有更好的解決方案了？

答案是引入鏈路追蹤系統(tǒng)。

什么是鏈路追蹤？

分布式鏈路追蹤就是將一次分布式請(qǐng)求還原成調(diào)用鏈路，將一次分布式請(qǐng)求的調(diào)用情況集中展示，比如各個(gè)服務(wù)節(jié)點(diǎn)上的耗時(shí)、請(qǐng)求具體到達(dá)哪臺(tái)機(jī)器上、每個(gè)服務(wù)節(jié)點(diǎn)的請(qǐng)求狀態(tài)等等。

鏈路跟蹤主要功能：

• 故障快速定位：可以通過(guò)調(diào)用鏈結(jié)合業(yè)務(wù)日志快速定位錯(cuò)誤信息。
• 鏈路性能可視化：各個(gè)階段鏈路耗時(shí)、服務(wù)依賴關(guān)系可以通過(guò)可視化界面展現(xiàn)出來(lái)。
• 鏈路分析：通過(guò)分析鏈路耗時(shí)、服務(wù)依賴關(guān)系可以得到用戶的行為路徑，匯總分析應(yīng)用在很多業(yè)務(wù)場(chǎng)景。

鏈路追蹤基本原理

鏈路追蹤系統(tǒng)（可能）最早是由Goggle公開(kāi)發(fā)布的一篇論文

《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》

被大家廣泛熟悉，所以各位技術(shù)大牛們?nèi)绻泻谖淦鞑灰仄饋?lái)趕緊去發(fā)表論文吧。

在這篇著名的論文中主要講述了Dapper鏈路追蹤系統(tǒng)的基本原理和關(guān)鍵技術(shù)點(diǎn)。接下來(lái)挑幾個(gè)重點(diǎn)的技術(shù)點(diǎn)詳細(xì)給大家介紹一下。

Trace

Trace的含義比較直觀，就是鏈路，指一個(gè)請(qǐng)求經(jīng)過(guò)所有服務(wù)的路徑，可以用下面樹(shù)狀的圖形表示。

圖中一條完整的鏈路是：chrome ->服務(wù)A ->服務(wù)B ->服務(wù)C ->服務(wù)D ->服務(wù)E ->服務(wù)C ->服務(wù)A ->chrome。服務(wù)間經(jīng)過(guò)的局部鏈路構(gòu)成了一條完整的鏈路，其中每一條局部鏈路都用一個(gè)全局唯一的traceid來(lái)標(biāo)識(shí)。

Span

在上圖中可以看出來(lái)請(qǐng)求經(jīng)過(guò)了服務(wù)A，同時(shí)服務(wù)A又調(diào)用了服務(wù)B和服務(wù)C，但是先調(diào)的服務(wù)B還是服務(wù)C呢？從圖中很難看出來(lái)，只有通過(guò)查看源碼才知道順序。

為了表達(dá)這種父子關(guān)系引入了Span的概念。

同一層級(jí)parent id相同，span id不同，span id從小到大表示請(qǐng)求的順序，從下圖中可以很明顯看出服務(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é)：通過(guò)事先在日志中埋點(diǎn)，找出相同traceId的日志，再加上parent id和span id就可以將一條完整的請(qǐng)求調(diào)用鏈串聯(lián)起來(lái)。

Annotations

Dapper中還定義了annotation的概念，用于用戶自定義事件，用來(lái)輔助定位問(wèn)題。

通常包含四個(gè)注解信息：

cs：Client Start，表示客戶端發(fā)起請(qǐng)求；

sr：ServerReceived，表示服務(wù)端收到請(qǐng)求；

ss：Server Send，表示服務(wù)端完成處理，并將結(jié)果發(fā)送給客戶端；

cr：ClientReceived，表示客戶端獲取到服務(wù)端返回信息；

上圖中描述了一次請(qǐng)求和響應(yīng)的過(guò)程，四個(gè)點(diǎn)也就是對(duì)應(yīng)四個(gè)Annotation事件。

如下面的圖表示從客戶端調(diào)用服務(wù)端的一次完整過(guò)程。如果要計(jì)算一次調(diào)用的耗時(shí)，只需要將客戶端接收的時(shí)間點(diǎn)減去客戶端開(kāi)始的時(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ǔ)端。通過(guò)帶外數(shù)據(jù)，可以在存儲(chǔ)端分析更多鏈路的細(xì)節(jié)。

帶內(nèi)數(shù)據(jù)如traceid,spanid,parentid，用來(lái)標(biāo)識(shí)trace，span，以及span在一個(gè)trace中的位置，這些數(shù)據(jù)需要從鏈路的起點(diǎn)一直傳遞到終點(diǎn)。通過(guò)帶內(nèi)數(shù)據(jù)的傳遞，可以將一個(gè)鏈路的所有過(guò)程串起來(lái)。

采樣

由于每一個(gè)請(qǐng)求都會(huì)生成一個(gè)鏈路，為了減少性能消耗，避免存儲(chǔ)資源的浪費(fèi)，dapper并不會(huì)上報(bào)所有的span數(shù)據(jù)，而是使用采樣的方式。舉個(gè)例子，每秒有1000個(gè)請(qǐng)求訪問(wèn)系統(tǒng)，如果設(shè)置采樣率為1/1000，那么只會(huì)上報(bào)一個(gè)請(qǐng)求到存儲(chǔ)端。

通過(guò)采集端自適應(yīng)地調(diào)整采樣率，控制span上報(bào)的數(shù)量，可以在發(fā)現(xiàn)性能瓶頸的同時(shí)，有效減少性能損耗。

存儲(chǔ)

鏈路中的span數(shù)據(jù)經(jīng)過(guò)收集和上報(bào)后會(huì)集中存儲(chǔ)在一個(gè)地方，Dapper使用了BigTable數(shù)據(jù)倉(cāng)庫(kù)，常用的存儲(chǔ)還有ElasticSearch, HBase, In-memory DB等。

業(yè)界常用鏈路追蹤系統(tǒng)

Google Dapper論文發(fā)出來(lái)之后，很多公司基于鏈路追蹤的基本原理給出了各自的解決方案，如Twitter的Zipkin，Uber的Jaeger，pinpoint，Apache開(kāi)源的skywalking，還有國(guó)產(chǎn)如阿里的鷹眼，美團(tuán)的Mtrace，滴滴Trace，新浪的Watchman，京東的Hydra，不過(guò)國(guó)內(nèi)的這些基本都沒(méi)有開(kāi)源。

為了便于各系統(tǒng)間能彼此兼容互通，OpenTracing組織制定了一系列標(biāo)準(zhǔn)，旨在讓各系統(tǒng)提供統(tǒng)一的接口。

下面對(duì)比一下幾個(gè)開(kāi)源組件，方便日后大家做技術(shù)選型。

附各大開(kāi)源組件的地址：

• zipkin? ->https://zipkin.io/
• Jaeger? ->https://www.jaegertracing.io/
• Pinpoint? ->https://github.com/pinpoint-apm/pinpoint
• SkyWalking? ->? http://skywalking.apache.org/

接下來(lái)介紹一下Zipkin基本實(shí)現(xiàn)。

分布式鏈路追蹤系統(tǒng)Zipkin實(shí)現(xiàn)

Zipkin 是 Twitter 的一個(gè)開(kāi)源項(xiàng)目，它基于 Google Dapper 實(shí)現(xiàn)，它致力于收集服務(wù)的定時(shí)數(shù)據(jù)，以解決微服務(wù)架構(gòu)中的延遲問(wèn)題，包括數(shù)據(jù)的收集、存儲(chǔ)、查找和展現(xiàn)。

Zipkin基本架構(gòu)

在服務(wù)運(yùn)行的過(guò)程中會(huì)產(chǎn)生很多鏈路信息，產(chǎn)生數(shù)據(jù)的地方可以稱之為Reporter。將鏈路信息通過(guò)多種傳輸方式如HTTP，RPC，kafka消息隊(duì)列等發(fā)送到Zipkin的采集器，Zipkin處理后最終將鏈路信息保存到存儲(chǔ)器中。運(yùn)維人員通過(guò)UI界面調(diào)用接口即可查詢調(diào)用鏈信息。

Zipkin核心組件

Zipkin有四大核心組件

（1）Collector

一旦Collector采集線程獲取到鏈路追蹤數(shù)據(jù)，Zipkin就會(huì)對(duì)其進(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)維人員快速定位線上問(wèn)題。query service提供了簡(jiǎn)單的json api來(lái)查找和檢索數(shù)據(jù)。

（4）Web UI

Zipkin 提供了基本查詢、搜索的web界面，運(yùn)維人員可以根據(jù)具體的調(diào)用鏈信息快速識(shí)別線上問(wèn)題。

總結(jié)

1. 分布式鏈路追蹤就是將每一次分布式請(qǐng)求還原成調(diào)用鏈路。
2. 鏈路追蹤的核心概念：Trace、Span、Annotation、帶內(nèi)和帶外數(shù)據(jù)、采樣、存儲(chǔ)。
3. 業(yè)界常用的開(kāi)源組件都是基于谷歌Dapper論文演變而來(lái)；
4. Zipkin核心組件有：Collector、Storage、Query Service、Web UI。