在經歷微服務的戰爭：級聯故障和雪崩 的 p0 級別事件後，你小手一攤便葛優躺了。開始進行自我覆盤，想起這次排查經歷，由於現在什麼基礎設施都還沒有，因此在接收到客戶反饋後，你是通過錯誤日誌進行問題檢查的。
但在級聯錯誤中，錯誤日誌產生的實在是太多了，不同的服務不同的鏈路幾乎都擠在一起，修復時間都主要用在了翻日誌上，翻了好幾頁才找到了相對有效的錯誤資訊。
如果下一次再出現類似的問題，可不得了，mttr 太久了，4 個 9 很快就會用完。這時候你想到了業界裡經常被提起的乙個利器，那就是 「分布式鏈路追蹤系統」。粗略來講，能夠看到各種應用的呼叫依賴：
首先看看由 uber 開發的 jaeger，jaeger 目前由 cloud native computing foundation(cncf)託管，是 cncf 的第七個頂級專案(於 2019 年 10 月畢業)：
在了解 jaeger 的各元件功能後，主要關注其整體的整體架構上的資料流**
jaeger 是乙個很經典的架構，由客戶端主動傳送鏈路資訊到 agent，agent 上報給 collector，再經由佇列，最終落地到儲存。再由另外的視覺化管理後台進行檢視和分析。
更具現化就是 上報 =》收集 =》儲存 =》分析的標準化流程。並且你會發現 jaeger 與 zipkin 在架構上差不多：
從時間上來看 jaeger 比 zipkin 晚四年，莫非是重複造輪子。經過翻閱，可得知做 jaeger 的主要原因是：
當時將跨度傳送到 zipkin 的唯一方法是通過 scribe，而 zipkin 支援的唯一高效能資料儲存是 cassandra。當時 uber 對這兩種技術都沒有經驗，因此選擇了自己構建乙個後端，該後端將一些自定義元件與 zipkin ui 結合在一起，形成了乙個完整的跟蹤系統。
更詳細可閱讀 evolving distributed tracing at uber engineering，可以了解很多細節。
鏈路追蹤系統的另一代表，基於日誌和流式計算去做的居多，像是阿里的鷹眼，滴滴的 traces，如下圖：
而本來就有原始的 n 個系統，如果想接入直接新的鏈路追蹤系統，還是非常麻煩的。因為原意想接入，必然是想解決原有系統的排查/定位問題，而不單單是為了新系統，因此單從接入的角度來講，大多不會就不會使用既有開源追蹤系統(除非歷史債務不大)，且資料量可能極大。
因此基於既有方法去改造來清洗資料再做成鏈路追蹤的模式也挺常見的，這之中日誌常常是乙個比較好的下手點，也就是去清洗某某資料，形成新的分析系統，再造乙個內部輪子。
另外近兩年基於 servicemesh 的 」無」 侵入式鏈路追蹤也廣受歡迎，似乎是乙個被看好的方向，其代表作之一 istio 便是使用 cncf 出身的 jaeger，且 jaeger 還相容 zipkin，在這點上 jaeger 完勝。
微服務鏈路追蹤原理
在微服務橫行的時代，服務化思維逐漸成為了程式設計師的基本思維模式，但是，由於絕大部分專案只是一味地增加服務，並沒有對其妥善管理，當介面出現問題時，很難從錯綜複雜的服務呼叫網路中找到問題根源，從而錯失了止損的 時機。而鏈路追蹤的出現正是為了解決這種問題，它可以在複雜的服務呼叫中定位問題，還可以在新人加...
微服務的鏈路追蹤概述
微服務架構下的問題 在大型系統的微服務化構建中，乙個系統會被拆分成許多模組。這些模組負責不同的功能，組合成系 統，最終可以提供豐富的功能。在這種架構中，一次請求往往需要涉及到多個服務。網際網路應用構建在 不同的軟體模組集上，這些軟體模組，有可能是由不同的團隊開發 可能使用不同的程式語言來實現 有可能...
skywalking原理 微服務鏈路追蹤原理
背景介紹 在微服務橫行的時代，服務化思維逐漸成為了程式設計師的基本思維模式，但是，由於絕大部分專案只是一味地增加服務，並沒有對其妥善管理，當介面出現問題時，很難從錯綜複雜的服務呼叫網路中找到問題根源，從而錯失了止損的 時機。而鏈路追蹤的出現正是為了解決這種問題，它可以在複雜的服務呼叫中定位問題，還可...