[[246529]]

這幾個(gè)工具對(duì)復(fù)雜軟件系統(tǒng)中的實(shí)時(shí)事件做了可視化，能幫助你快速發(fā)現(xiàn)性能問(wèn)題。

分布式追蹤系統(tǒng)能夠從頭到尾地追蹤跨越了多個(gè)應(yīng)用、服務(wù)、數(shù)據(jù)庫(kù)以及像代理這樣的中間件的分布式軟件的請(qǐng)求。它能幫助你更深入地理解系統(tǒng)中到底發(fā)生了什么。追蹤系統(tǒng)以圖形化的方式，展示出每個(gè)已知步驟以及某個(gè)請(qǐng)求在每個(gè)步驟上的耗時(shí)。

用戶可以通過(guò)這些展示來(lái)判斷系統(tǒng)的哪個(gè)環(huán)節(jié)有延遲或阻塞，當(dāng)請(qǐng)求失敗時(shí)，運(yùn)維和開發(fā)人員可以看到準(zhǔn)確的問(wèn)題源頭，而不需要去測(cè)試整個(gè)系統(tǒng)，比如用二叉查找樹的方法去定位問(wèn)題。在開發(fā)迭代的過(guò)程中，追蹤系統(tǒng)還能夠展示出可能引起性能變化的環(huán)節(jié)。通過(guò)異常行為的警告自動(dòng)地感知到性能的退化，總是比客戶告訴你要好。

這種追蹤是怎么工作的呢？給每個(gè)請(qǐng)求分配一個(gè)特殊 ID，這個(gè) ID 通常會(huì)插入到請(qǐng)求頭部中。它唯一標(biāo)識(shí)了對(duì)應(yīng)的事務(wù)。一般把事務(wù)叫做蹤跡trace，“蹤跡”是整個(gè)事務(wù)的抽象概念。每一個(gè)“蹤跡”由單元span組成，“單元”代表著一次請(qǐng)求中真正執(zhí)行的操作，比如一次服務(wù)調(diào)用，一次數(shù)據(jù)庫(kù)請(qǐng)求等。每一個(gè)“單元”也有自己唯一的 ID。“單元”之下也可以創(chuàng)建子“單元”，子“單元”可以有多個(gè)父“單元”。

當(dāng)一次事務(wù)（或者說(shuō)蹤跡）運(yùn)行過(guò)之后，就可以在追蹤系統(tǒng)的表示層上搜索了。有幾個(gè)工具可以用作表示層，我們下文會(huì)討論，不過(guò)，我們先看下面的圖，它是我在 Istio walkthrough 視頻教程中提到的 Jaeger 界面，展示了單個(gè)蹤跡中的多個(gè)單元。很明顯，這個(gè)圖能讓你一目了然地對(duì)事務(wù)有更深的了解。

這個(gè)演示使用了 Istio 內(nèi)置的 OpenTracing 實(shí)現(xiàn)，所以我甚至不需要修改自己的應(yīng)用代碼就可以獲得追蹤數(shù)據(jù)。我也用到了 Jaeger，它是兼容 OpenTracing 的。

那么 OpenTracing 到底是什么呢？我們來(lái)看看。

OpenTracing API

OpenTracing 是源自 Zipkin 的規(guī)范，以提供跨平臺(tái)兼容性。它提供了對(duì)廠商中立的 API，用來(lái)向應(yīng)用程序添加追蹤功能并將追蹤數(shù)據(jù)發(fā)送到分布式的追蹤系統(tǒng)。按照 OpenTracing 規(guī)范編寫的庫(kù)，可以被任何兼容 OpenTracing 的系統(tǒng)使用。采用這個(gè)開放標(biāo)準(zhǔn)的開源工具有 Zipkin、Jaeger 和 Appdash 等。甚至像 Datadog 和 Instana 這種付費(fèi)工具也在采用。因?yàn)楝F(xiàn)在 OpenTracing 已經(jīng)無(wú)處不在，這樣的趨勢(shì)有望繼續(xù)發(fā)展下去。

OpenCensus

OpenTracing 已經(jīng)說(shuō)過(guò)了，可 OpenCensus 又是什么呢？它在搜索結(jié)果中老是出現(xiàn)。它是一個(gè)和 OpenTracing 完全不同或者互補(bǔ)的競(jìng)爭(zhēng)標(biāo)準(zhǔn)嗎？

這個(gè)問(wèn)題的答案取決于你的提問(wèn)對(duì)象。我先盡我所能地解釋一下它們的不同（按照我的理解）：OpenCensus 更加全面或者說(shuō)它包羅萬(wàn)象。OpenTracing 專注于建立開放的 API 和規(guī)范，而不是為每一種開發(fā)語(yǔ)言和追蹤系統(tǒng)都提供開放的實(shí)現(xiàn)。OpenCensus 不僅提供規(guī)范，還提供開發(fā)語(yǔ)言的實(shí)現(xiàn)，和連接協(xié)議，而且它不僅只做追蹤，還引入了額外的度量指標(biāo)，這些一般不在分布式追蹤系統(tǒng)的職責(zé)范圍。

使用 OpenCensus，我們能夠在運(yùn)行著應(yīng)用程序的主機(jī)上查看追蹤數(shù)據(jù)，但它也有個(gè)可插拔的導(dǎo)出器系統(tǒng)，用于導(dǎo)出數(shù)據(jù)到中心聚合器。目前 OpenCensus 團(tuán)隊(duì)提供的導(dǎo)出器包括 Zipkin、Prometheus、Jaeger、Stackdriver、Datadog 和 SignalFx，不過(guò)任何人都可以創(chuàng)建一個(gè)導(dǎo)出器。

依我看這兩者有很多重疊的部分，沒(méi)有哪個(gè)一定比另外一個(gè)好，但是重要的是，要知道它們做什么事情和不做什么事情。OpenTracing 主要是一個(gè)規(guī)范，具體的實(shí)現(xiàn)和獨(dú)斷的設(shè)計(jì)由其他人來(lái)做。OpenCensus 更加獨(dú)斷地為本地組件提供了全面的解決方案，但是仍然需要其他系統(tǒng)做遠(yuǎn)程的聚合。

可選工具

Zipkin

Zipkin 是最早出現(xiàn)的這類工具之一。 谷歌在 2010 年發(fā)表了介紹其內(nèi)部追蹤系統(tǒng) Dapper 的論文，Twitter 以此為基礎(chǔ)開發(fā)了 Zipkin。Zipkin 的開發(fā)語(yǔ)言 Java，用 Cassandra 或 ElasticSearch 作為可擴(kuò)展的存儲(chǔ)后端，這些選擇能滿足大部分公司的需求。Zipkin 支持的*** Java 版本是 Java 6，它也使用了 Thrift 的二進(jìn)制通信協(xié)議，Thrift 在 Twitter 的系統(tǒng)中很流行，現(xiàn)在作為 Apache 項(xiàng)目在托管。

這個(gè)系統(tǒng)包括上報(bào)器（客戶端）、數(shù)據(jù)收集器、查詢服務(wù)和一個(gè) web 界面。Zipkin 只傳輸一個(gè)帶事務(wù)上下文的蹤跡 ID 來(lái)告知接收者追蹤的進(jìn)行，所以說(shuō)在生產(chǎn)環(huán)境中是安全的。每一個(gè)客戶端收集到的數(shù)據(jù)，會(huì)異步地傳輸?shù)綌?shù)據(jù)收集器。收集器把這些單元的數(shù)據(jù)存到數(shù)據(jù)庫(kù)，web 界面負(fù)責(zé)用可消費(fèi)的格式展示這些數(shù)據(jù)給用戶。客戶端傳輸數(shù)據(jù)到收集器有三種方式：HTTP、Kafka 和 Scribe。

Zipkin 社區(qū) 還提供了 Brave，一個(gè)跟 Zipkin 兼容的 Java 客戶端的實(shí)現(xiàn)。由于 Brave 沒(méi)有任何依賴，所以它不會(huì)拖累你的項(xiàng)目，也不會(huì)使用跟你們公司標(biāo)準(zhǔn)不兼容的庫(kù)來(lái)搞亂你的項(xiàng)目。除 Brave 之外，還有很多其他的 Zipkin 客戶端實(shí)現(xiàn)，因?yàn)?Zipkin 和 OpenTracing 標(biāo)準(zhǔn)是兼容的，所以這些實(shí)現(xiàn)也能用到其他的分布式追蹤系統(tǒng)中。流行的 Spring 框架中一個(gè)叫 Spring Cloud Sleuth 的分布式追蹤組件，它和 Zipkin 是兼容的。

Jaeger

Jaeger 來(lái)自 Uber，是一個(gè)比較新的項(xiàng)目，CNCF（云原生計(jì)算基金會(huì)）已經(jīng)把 Jaeger 托管為孵化項(xiàng)目。Jaeger 使用 Golang 開發(fā)，因此你不用擔(dān)心在服務(wù)器上安裝依賴的問(wèn)題，也不用擔(dān)心開發(fā)語(yǔ)言的解釋器或虛擬機(jī)的開銷。和 Zipkin 類似，Jaeger 也支持用 Cassandra 和 ElasticSearch 做可擴(kuò)展的存儲(chǔ)后端。Jaeger 也完全兼容 OpenTracing 標(biāo)準(zhǔn)。

Jaeger 的架構(gòu)跟 Zipkin 很像，有客戶端（上報(bào)器）、數(shù)據(jù)收集器、查詢服務(wù)和一個(gè) web 界面，不過(guò)它還有一個(gè)在各個(gè)服務(wù)器上運(yùn)行著的代理，負(fù)責(zé)在服務(wù)器本地做數(shù)據(jù)聚合。代理通過(guò)一個(gè) UDP 連接接收數(shù)據(jù)，然后分批處理，發(fā)送到數(shù)據(jù)收集器。收集器接收到的數(shù)據(jù)是 Thrift 協(xié)議的格式，它把數(shù)據(jù)存到 Cassandra 或者 ElasticSearch 中。查詢服務(wù)能直接訪問(wèn)數(shù)據(jù)庫(kù)，并給 web 界面提供所需的信息。

默認(rèn)情況下，Jaeger 客戶端不會(huì)采集所有的追蹤數(shù)據(jù)，只抽樣了 0.1% 的（ 1000 個(gè)采 1 個(gè)）追蹤數(shù)據(jù)。對(duì)大多數(shù)系統(tǒng)來(lái)說(shuō)，保留所有的追蹤數(shù)據(jù)并傳輸?shù)脑捑吞嗔恕２贿^(guò)，通過(guò)配置代理可以調(diào)整這個(gè)值，客戶端會(huì)從代理獲取自己的配置。這個(gè)抽樣并不是完全隨機(jī)的，并且正在變得越來(lái)越好。Jaeger 使用概率抽樣，試圖對(duì)是否應(yīng)該對(duì)新蹤跡進(jìn)行抽樣進(jìn)行有根據(jù)的猜測(cè)。 自適應(yīng)采樣已經(jīng)在路線圖當(dāng)中，它將通過(guò)添加額外的、能夠幫助做決策的上下文來(lái)改進(jìn)采樣算法。

Appdash

Appdash 也是一個(gè)用 Golang 寫的分布式追蹤系統(tǒng)，和 Jaeger 一樣。Appdash 是 Sourcegraph 公司基于谷歌的 Dapper 和 Twitter 的 Zipkin 開發(fā)的。同樣的，它也支持 Opentracing 標(biāo)準(zhǔn)，不過(guò)這是后來(lái)添加的功能，依賴了一個(gè)與默認(rèn)組件不同的組件，因此增加了風(fēng)險(xiǎn)和復(fù)雜度。

從高層次來(lái)看，Appdash 的架構(gòu)主要有三個(gè)部分：客戶端、本地收集器和遠(yuǎn)程收集器。因?yàn)闆](méi)有很多文檔，所以這個(gè)架構(gòu)描述是基于對(duì)系統(tǒng)的測(cè)試以及查看源碼。寫代碼時(shí)需要把 Appdash 的客戶端添加進(jìn)來(lái)。Appdash 提供了 Python、Golang 和 Ruby 的實(shí)現(xiàn)，不過(guò) OpenTracing 庫(kù)可以與 Appdash 的 OpenTracing 實(shí)現(xiàn)一起使用。 客戶端收集單元數(shù)據(jù)，并將它們發(fā)送到本地收集器。然后，本地收集器將數(shù)據(jù)發(fā)送到中心的 Appdash 服務(wù)器，這個(gè)服務(wù)器上運(yùn)行著自己的本地收集器，它的本地收集器是其他所有節(jié)點(diǎn)的遠(yuǎn)程收集器。