微服務的戰(zhàn)爭：選型？分布式鏈路追蹤
本文轉(zhuǎn)載自微信公眾號「腦子進煎魚了」，作者陳煎魚 。轉(zhuǎn)載本文請聯(lián)系腦子進煎魚了公眾號。
“微服務的戰(zhàn)爭” 是一個關于微服務設計思考的系列題材，主要是針對在微服務化后所出現(xiàn)的一些矛盾/沖突點，不涉及具體某一個知識點深入。如果你有任何問題或建議，歡迎隨時交流。
背景
在經(jīng)歷微服務的戰(zhàn)爭：級聯(lián)故障和雪崩 的 P0 級別事件后，你小手一攤便葛優(yōu)躺了。開始進行自我復盤，想起這次排查經(jīng)歷，由于現(xiàn)在什么基礎設施都還沒有，因此在接收到客戶反饋后，你是通過錯誤日志進行問題檢查的。
但在級聯(lián)錯誤中，錯誤日志產(chǎn)生的實在是太多了，不同的服務不同的鏈路幾乎都擠在一起，修復時間都主要用在了翻日志上，翻了好幾頁才找到了相對有效的錯誤信息。
如果下一次在出現(xiàn)類似的問題，可不得了，MTTR 太久了，4 個 9 很快就會用完。這時候你想到了業(yè)界里經(jīng)常被提起的一個利器，那就是 “分布式鏈路追蹤系統(tǒng)”。粗略來講，能夠看到各種應用的調(diào)用依賴：
其中最著名的是 Google Dapper 論文所介紹的 Dapper。源于 Google 為了解決可能由不同團隊，不同語言，不同模塊，部署在不同服務器，不同數(shù)據(jù)中心的所帶來的軟件復雜性(很難去分析，無法做定位)，構建了一個的分布式跟蹤系統(tǒng)：
自此就開啟了業(yè)界在分布式鏈路的啟發(fā)/啟蒙之路，很多現(xiàn)在出名的分布式鏈路追蹤系統(tǒng)都是基于 Google Dapper 論文發(fā)展而來，基本原理和架構都大同小異。若對此有興趣的可具體查看 Google Dapper，非常有意思。
(Google Dapper 中存在跟蹤樹和 Span 的概念)
選型?有哪些
想做鏈路追蹤，那必然要挑選一款開源產(chǎn)品作為你的分布式鏈路追蹤系統(tǒng)，不大可能再造一個全新的，先實現(xiàn)業(yè)務目的最重要。因此在網(wǎng)上一搜，發(fā)現(xiàn)如下大量產(chǎn)品：
- Twitter：Zipkin。
- Uber：Jaeger。
- Elastic Stack：Elastic APM。
- Apache：SkyWalking(國內(nèi)開源愛好者吳晟開源)。
- Naver：Pinpoint(韓國公司開發(fā))。
- 阿里：鷹眼。
- 大眾點評：Cat。
- 京東：Hydra。
隨手一搜就發(fā)現(xiàn)這類產(chǎn)品特別的多，并且據(jù)聞各大公司都有自己的一套內(nèi)部鏈路追蹤系統(tǒng)，這下你可犯了大難。他們之間都是基于 Google Dapper 演進出來的，那本質(zhì)上到底有什么區(qū)別，怎么延伸出這么多的新產(chǎn)品?
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ù)并寫入其他的存儲介質(zhì)(Cassandra，Elasticsearch)。
在了解 Jaeger 的各組件功能后，主要關注其整體的整體架構上的數(shù)據(jù)流轉(zhuǎn)：
Jaeger 是一個很經(jīng)典的架構，由客戶端主動發(fā)送鏈路信息到 Agent，Agent 上報給 Collector，再經(jīng)由隊列，最終落地到存儲。再由另外的可視化管理后臺進行查看和分析。
更具現(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 晚四年，莫非是重復造輪子。經(jīng)過翻閱，可得知做 Jaeger 的主要原因是：
當時將跨度發(fā)送到 Zipkin 的唯一方法是通過 Scribe，而 Zipkin 支持的唯一高性能數(shù)據(jù)存儲是 Cassandra。當時 Uber 對這兩種技術都沒有經(jīng)驗，因此選擇了自己構建一個后端，該后端將一些自定義組件與 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)，再造一個內(nèi)部輪子。
另外近兩年基于 ServiceMesh 的 ”無” 侵入式鏈路追蹤也廣受歡迎，似乎是一個被看好的方向，其代表作之一 Istio 便是使用 CNCF 出身的 Jaeger，且 Jaeger 還兼容 Zipkin，在這點上 Jaeger 完勝。
