微服務的戰(zhàn)爭：選型？分布式鏈路追蹤

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

背景

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

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

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

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

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

（Google Dapper 中存在跟蹤樹和 Span 的概念）

選型？有哪些

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

• Twitter：Zipkin。
• Uber：Jaeger。
• Elastic Stack：Elastic APM。
• Apache：SkyWalking（國內開源愛好者吳晟開源）。
• Naver：Pinpoint（韓國公司開發(fā)）。
• 阿里：鷹眼。
• 大眾點評：Cat。
• 京東：Hydra。

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

Jaeger

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

• Jaeger Client：Jaeger 客戶端，是 Jaeger 針對 OpenTracing API 的特定語言實現(xiàn)，可用于手動或通過與 OpenTracing 集成的各種現(xiàn)有開源框架（例如Flask，Dropwizard，gRPC等）來檢測應用程序以進行分布式跟蹤。

• Jaeger Agent：Jaeger 客戶端代理，在 UDP 端口上監(jiān)聽所接受的跨度并將其分批發(fā)送給 Collector。

• Jaeger Collector：Jaeger 收集器，顧名思義是面向 Agent，用于收集/管理鏈路的追蹤信息。

• Jaeger Query：數(shù)據(jù)查詢與前端界面展示。

• Jaeger Ingester：可從 Kafka 讀取數(shù)據(jù)并寫入其他的存儲介質（Cassandra，Elasticsearch）。

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

Jaeger 是一個很經典的架構，由客戶端主動發(fā)送鏈路信息到 Agent，Agent 上報給 Collector，再經由隊列，最終落地到存儲。再由另外的可視化管理后臺進行查看和分析。

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

• Zipkin Collector：Zipkin 收集器，用于收集/管理鏈路的追蹤信息。

• Storage：Zipkin 數(shù)據(jù)存儲，支持 Cassandra、ElasticSearch 和 MySQL 等第三方存儲。

• Zipkin Query Service：數(shù)據(jù)存儲并建立索引后，用于查找和檢索跟蹤信息。

• Web UI：數(shù)據(jù)查詢與前端界面展示。

從時間上來看 Jaeger 比 Zipkin 晚四年，莫非是重復造輪子。經過翻閱，可得知做 Jaeger 的主要原因是：

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

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

阿里鷹眼

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

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

總結

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

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

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

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