「微服務的戰爭」 是一個關於微服務設計思考的系列題材，主要是針對在微服務化後所出現的一些矛盾/衝突點，不涉及具體某一個知識點深刻。若是你有任何問題或建議，歡迎隨時交流。前端
背景
在經歷微服務的戰爭：級聯故障和雪崩 的 P0 級別事件後，你小手一攤便葛優躺了。開始進行自我覆盤，想起此次排查經歷，因爲如今什麼基礎設施都尚未，所以在接收到客戶反饋後，你是經過錯誤日誌進行問題檢查的。web
但在級聯錯誤中，錯誤日誌產生的實在是太多了，不一樣的服務不一樣的鏈路幾乎都擠在一塊兒，修復時間都主要用在了翻日誌上，翻了好幾頁才找到了相對有效的錯誤信息。後端
若是下一次在出現相似的問題，可不得了，MTTR 過久了，4 個 9 很快就會用完。這時候你想到了業界裏常常被提起的一個利器，那就是 「分佈式鏈路追蹤系統」。粗略來說，可以看到各類應用的調用依賴：服務器
其中最著名的是 Google Dapper 論文所介紹的 Dapper。源於 Google 爲了解決可能由不一樣團隊，不一樣語言，不一樣模塊，部署在不一樣服務器，不一樣數據中心的所帶來的軟件複雜性（很難去分析，沒法作定位），構建了一個的分佈式跟蹤系統：微信
自此就開啓了業界在分佈式鏈路的啓發/啓蒙之路，不少如今出名的分佈式鏈路追蹤系統都是基於 Google Dapper 論文發展而來，基本原理和架構都大同小異。若對此有興趣的可具體查看 Google Dapper，很是有意思。架構
（Google Dapper 中存在跟蹤樹和 Span 的概念）app
選型？有哪些
想作鏈路追蹤，那必然要挑選一款開源產品做爲你的分佈式鏈路追蹤系統，不大可能再造一個全新的，先實現業務目的最重要。所以在網上一搜，發現以下大量產品：框架
-
Twitter：Zipkin。 -
Uber：Jaeger。 -
Elastic Stack：Elastic APM。 -
Apache：SkyWalking（國內開源愛好者吳晟開源）。 -
Naver：Pinpoint（韓國公司開發）。 -
阿里：鷹眼。 -
大衆點評：Cat。 -
京東：Hydra。
隨手一搜就發現這類產品特別的多，而且據聞各大公司都有本身的一套內部鏈路追蹤系統，這下你可犯了大難。他們之間都是基於 Google Dapper 演進出來的，那本質上到底有什麼區別，怎麼延伸出這麼多的新產品？編輯器
Jaeger
首先看看由 Uber 開發的 Jaeger，Jaeger 目前由 Cloud Native Computing Foundation（CNCF）託管，是 CNCF 的第七個頂級項目（於 2019 年 10 月畢業）：分佈式
-
Jaeger Client：Jaeger 客戶端，是 Jaeger 針對 OpenTracing API 的特定語言實現，可用於手動或經過與 OpenTracing 集成的各類現有開源框架（例如Flask，Dropwizard，gRPC等）來檢測應用程序以進行分佈式跟蹤。
-
Jaeger Agent：Jaeger 客戶端代理，在 UDP 端口上監聽所接受的跨度並將其分批發送給 Collector。
-
Jaeger Collector：Jaeger 收集器，顧名思義是面向 Agent，用於收集/管理鏈路的追蹤信息。
-
Jaeger Query：數據查詢與前端界面展現。
-
Jaeger Ingester：可從 Kafka 讀取數據並寫入其餘的存儲介質（Cassandra，Elasticsearch）。
在瞭解 Jaeger 的各組件功能後，主要關注其總體的總體架構上的數據流轉：
Jaeger 是一個很經典的架構，由客戶端主動發送鏈路信息到 Agent，Agent 上報給 Collector，再經由隊列，最終落地到存儲。再由另外的可視化管理後臺進行查看和分析。
更具現化就是 上報 =》收集 =》存儲 =》分析的標準化流程。而且你會發現 Jaeger 與 Zipkin 在架構上差很少：
-
Zipkin Collector：Zipkin 收集器，用於收集/管理鏈路的追蹤信息。
-
Storage：Zipkin 數據存儲，支持 Cassandra、ElasticSearch 和 MySQL 等第三方存儲。
-
Zipkin Query Service：數據存儲並創建索引後，用於查找和檢索跟蹤信息。
-
Web UI：數據查詢與前端界面展現。
從時間上來看 Jaeger 比 Zipkin 晚四年，莫非是重複造輪子。通過翻閱，可得知作 Jaeger 的主要緣由是：
當時將跨度發送到 Zipkin 的惟一方法是經過 Scribe，而 Zipkin 支持的惟一高性能數據存儲是 Cassandra。當時 Uber 對這兩種技術都沒有經驗，所以選擇了本身構建一個後端，該後端將一些自定義組件與 Zipkin UI 結合在一塊兒，造成了一個完整的跟蹤系統。
更詳細可閱讀 Evolving Distributed Tracing at Uber Engineering，能夠了解不少細節。
阿里鷹眼
鏈路追蹤系統的另外一表明，基於日誌和流式計算去作的居多，像是阿里的鷹眼，滴滴的 traces，以下圖：
更具體可見《阿里巴巴鷹眼技術解密》 和 《異構系統鏈路追蹤——滴滴 trace 實踐》 在大會上的分享，這裏就再也不贅述了，推薦好奇或憂愁鏈路追蹤落地的小夥伴們閱讀。
總結
大多數在初始選型時都會選擇親和性比較強的追蹤系統，就像是 Jaeger 屬於 Go，Zipkin、Skywalking 是 Java 系居多，三者都徹底兼容 OpenTracing，只是架構上多少有些不一樣，且都是基於 Google Dapper 發散，所以所支持的基本功能和查詢頁面優雅與否很重要。
而原本就有原始的 N 個系統，若是想接入直接新的鏈路追蹤系統，仍是很是麻煩的。由於原意想接入，必然是想解決原有系統的排查/定位問題，而不僅僅是爲了新系統，所以單從接入的角度來說，大多不會就不會使用既有開源追蹤系統（除非歷史債務不大），且數據量可能極大。
所以基於既有方法去改造來清洗數據再作成鏈路追蹤的模式也挺常見的，這之中日誌經常是一個比較好的下手點，也就是去清洗某某數據，造成新的分析系統，再造一個內部輪子。
另外近兩年基於 ServiceMesh 的 」無」 侵入式鏈路追蹤也廣受歡迎，彷佛是一個被看好的方向，其表明做之一 Istio 即是使用 CNCF 出身的 Jaeger，且 Jaeger 還兼容 Zipkin，在這點上 Jaeger 完勝。
本文分享自微信公衆號 - 腦子進煎魚了（eddycjy）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。