[[341705]]

本文轉(zhuǎn)載自微信公眾號(hào)「腦子進(jìn)煎魚了」，作者陳煎魚 。轉(zhuǎn)載本文請(qǐng)聯(lián)系腦子進(jìn)煎魚了公眾號(hào)。  

 “微服務(wù)的戰(zhàn)爭(zhēng)” 是一個(gè)關(guān)于微服務(wù)設(shè)計(jì)思考的系列題材，主要是針對(duì)在微服務(wù)化后所出現(xiàn)的一些矛盾/沖突點(diǎn)，不涉及具體某一個(gè)知識(shí)點(diǎn)深入。如果你有任何問題或建議，歡迎隨時(shí)交流。

背景

在經(jīng)歷微服務(wù)的戰(zhàn)爭(zhēng)：級(jí)聯(lián)故障和雪崩 的 P0 級(jí)別事件后，你小手一攤便葛優(yōu)躺了。開始進(jìn)行自我復(fù)盤，想起這次排查經(jīng)歷，由于現(xiàn)在什么基礎(chǔ)設(shè)施都還沒有，因此在接收到客戶反饋后，你是通過錯(cuò)誤日志進(jìn)行問題檢查的。

但在級(jí)聯(lián)錯(cuò)誤中，錯(cuò)誤日志產(chǎn)生的實(shí)在是太多了，不同的服務(wù)不同的鏈路幾乎都擠在一起，修復(fù)時(shí)間都主要用在了翻日志上，翻了好幾頁(yè)才找到了相對(duì)有效的錯(cuò)誤信息。

如果下一次在出現(xiàn)類似的問題，可不得了，MTTR 太久了，4 個(gè) 9 很快就會(huì)用完。這時(shí)候你想到了業(yè)界里經(jīng)常被提起的一個(gè)利器，那就是 “分布式鏈路追蹤系統(tǒng)”。粗略來(lái)講，能夠看到各種應(yīng)用的調(diào)用依賴：

其中最著名的是 Google Dapper 論文所介紹的 Dapper。源于 Google 為了解決可能由不同團(tuán)隊(duì)，不同語(yǔ)言，不同模塊，部署在不同服務(wù)器，不同數(shù)據(jù)中心的所帶來(lái)的軟件復(fù)雜性(很難去分析，無(wú)法做定位)，構(gòu)建了一個(gè)的分布式跟蹤系統(tǒng)：

自此就開啟了業(yè)界在分布式鏈路的啟發(fā)/啟蒙之路，很多現(xiàn)在出名的分布式鏈路追蹤系統(tǒng)都是基于 Google Dapper 論文發(fā)展而來(lái)，基本原理和架構(gòu)都大同小異。若對(duì)此有興趣的可具體查看 Google Dapper，非常有意思。

(Google Dapper 中存在跟蹤樹和 Span 的概念)

選型?有哪些

想做鏈路追蹤，那必然要挑選一款開源產(chǎn)品作為你的分布式鏈路追蹤系統(tǒng)，不大可能再造一個(gè)全新的，先實(shí)現(xiàn)業(yè)務(wù)目的最重要。因此在網(wǎng)上一搜，發(fā)現(xiàn)如下大量產(chǎn)品：

• Twitter：Zipkin。
• Uber：Jaeger。
• Elastic Stack：Elastic APM。
• Apache：SkyWalking(國(guó)內(nèi)開源愛好者吳晟開源)。
• Naver：Pinpoint(韓國(guó)公司開發(fā))。
• 阿里：鷹眼。
• 大眾點(diǎn)評(píng)：Cat。
• 京東：Hydra。

隨手一搜就發(fā)現(xiàn)這類產(chǎn)品特別的多，并且據(jù)聞各大公司都有自己的一套內(nèi)部鏈路追蹤系統(tǒng)，這下你可犯了大難。他們之間都是基于 Google Dapper 演進(jìn)出來(lái)的，那本質(zhì)上到底有什么區(qū)別，怎么延伸出這么多的新產(chǎn)品?

Jaeger

首先看看由 Uber 開發(fā)的 Jaeger，Jaeger 目前由 Cloud Native Computing Foundation(CNCF)托管，是 CNCF 的第七個(gè)頂級(jí)項(xiàng)目(于 2019 年 10 月畢業(yè))：

• Jaeger Client：Jaeger 客戶端，是 Jaeger 針對(duì) OpenTracing API 的特定語(yǔ)言實(shí)現(xiàn)，可用于手動(dòng)或通過與 OpenTracing 集成的各種現(xiàn)有開源框架(例如Flask，Dropwizard，gRPC等)來(lái)檢測(cè)應(yīng)用程序以進(jìn)行分布式跟蹤。
• Jaeger Agent：Jaeger 客戶端代理，在 UDP 端口上監(jiān)聽所接受的跨度并將其分批發(fā)送給 Collector。
• Jaeger Collector：Jaeger 收集器，顧名思義是面向 Agent，用于收集/管理鏈路的追蹤信息。
• Jaeger Query：數(shù)據(jù)查詢與前端界面展示。
• Jaeger Ingester：可從 Kafka 讀取數(shù)據(jù)并寫入其他的存儲(chǔ)介質(zhì)(Cassandra，Elasticsearch)。

在了解 Jaeger 的各組件功能后，主要關(guān)注其整體的整體架構(gòu)上的數(shù)據(jù)流轉(zhuǎn)：

Jaeger 是一個(gè)很經(jīng)典的架構(gòu)，由客戶端主動(dòng)發(fā)送鏈路信息到 Agent，Agent 上報(bào)給 Collector，再經(jīng)由隊(duì)列，最終落地到存儲(chǔ)。再由另外的可視化管理后臺(tái)進(jìn)行查看和分析。

更具現(xiàn)化就是 上報(bào) =》收集 =》存儲(chǔ) =》分析的標(biāo)準(zhǔn)化流程。并且你會(huì)發(fā)現(xiàn) Jaeger 與 Zipkin 在架構(gòu)上差不多：

• Zipkin Collector：Zipkin 收集器，用于收集/管理鏈路的追蹤信息。
• Storage：Zipkin 數(shù)據(jù)存儲(chǔ)，支持 Cassandra、ElasticSearch 和 MySQL 等第三方存儲(chǔ)。
• Zipkin Query Service：數(shù)據(jù)存儲(chǔ)并建立索引后，用于查找和檢索跟蹤信息。
• Web UI：數(shù)據(jù)查詢與前端界面展示。

從時(shí)間上來(lái)看 Jaeger 比 Zipkin 晚四年，莫非是重復(fù)造輪子。經(jīng)過翻閱，可得知做 Jaeger 的主要原因是：

當(dāng)時(shí)將跨度發(fā)送到 Zipkin 的唯一方法是通過 Scribe，而 Zipkin 支持的唯一高性能數(shù)據(jù)存儲(chǔ)是 Cassandra。當(dāng)時(shí) Uber 對(duì)這兩種技術(shù)都沒有經(jīng)驗(yàn)，因此選擇了自己構(gòu)建一個(gè)后端，該后端將一些自定義組件與 Zipkin UI 結(jié)合在一起，形成了一個(gè)完整的跟蹤系統(tǒng)。

更詳細(xì)可閱讀 Evolving Distributed Tracing at Uber Engineering，可以了解很多細(xì)節(jié)。

阿里鷹眼

鏈路追蹤系統(tǒng)的另一代表，基于日志和流式計(jì)算去做的居多，像是阿里的鷹眼，滴滴的 traces，如下圖：

更具體可見《阿里巴巴鷹眼技術(shù)解密》 和 《異構(gòu)系統(tǒng)鏈路追蹤——滴滴 trace 實(shí)踐》 在大會(huì)上的分享，這里就不再贅述了，推薦好奇或憂愁鏈路追蹤落地的小伙伴們閱讀。

總結(jié)

大多數(shù)在初始選型時(shí)都會(huì)選擇親和性比較強(qiáng)的追蹤系統(tǒng)，就像是 Jaeger 屬于 Go，Zipkin、Skywalking 是 Java 系居多，三者都完全兼容 OpenTracing，只是架構(gòu)上多少有些不同，且都是基于 Google Dapper 發(fā)散，因此所支持的基本功能和查詢頁(yè)面優(yōu)雅與否很重要。

而本來(lái)就有原始的 N 個(gè)系統(tǒng)，如果想接入直接新的鏈路追蹤系統(tǒng)，還是非常麻煩的。因?yàn)樵庀虢尤?，必然是想解決原有系統(tǒng)的排查/定位問題，而不單單是為了新系統(tǒng)，因此單從接入的角度來(lái)講，大多不會(huì)就不會(huì)使用既有開源追蹤系統(tǒng)(除非歷史債務(wù)不大)，且數(shù)據(jù)量可能極大。

因此基于既有方法去改造來(lái)清洗數(shù)據(jù)再做成鏈路追蹤的模式也挺常見的，這之中日志常常是一個(gè)比較好的下手點(diǎn)，也就是去清洗某某數(shù)據(jù)，形成新的分析系統(tǒng)，再造一個(gè)內(nèi)部輪子。

另外近兩年基于 ServiceMesh 的 ”無(wú)” 侵入式鏈路追蹤也廣受歡迎，似乎是一個(gè)被看好的方向，其代表作之一 Istio 便是使用 CNCF 出身的 Jaeger，且 Jaeger 還兼容 Zipkin，在這點(diǎn)上 Jaeger 完勝。