分佈式鏈路追蹤技術適⽤場景（問題場景）
場景描述
爲了⽀撐⽇益增⻓的龐⼤業務量，咱們會使⽤微服務架構設計咱們的系統，使得咱們的系統不只可以經過集羣部署抵擋流量的衝擊，⼜能根據業務進⾏靈活的擴展。
數據結構
那麼，在微服務架構下，⼀次請求少則通過三四次服務調⽤完成，多則跨越⼏⼗個甚⾄是上百個服務節點。那麼問題接踵⽽來：
1）如何動態展現服務的調⽤鏈路？（⽐如A服務調⽤了哪些其餘的服務—依賴關係）
架構
2）如何分析服務調⽤鏈路中的瓶頸節點並對其進⾏調優？(⽐如A—>B—>C，C服務處理時間特別⻓)
3）如何快速進⾏服務鏈路的故障發現？
app
這就是分佈式鏈路追蹤技術存在的⽬的和意義框架
分佈式鏈路追蹤技術
若是咱們在⼀個請求的調⽤處理過程當中，在各個鏈路節點都可以記錄下⽇志，並最終將⽇志進⾏集中可視化展現，那麼咱們想監控調⽤鏈路中的⼀些指標就有但願了~~~⽐如，請求到達哪一個服務實例？請求被處理的狀態怎樣？處理耗時怎樣？這些都可以分析出來了…
分佈式
分佈式環境下基於這種想法實現的監控技術就是就是分佈式鏈路追蹤（全鏈路追蹤）。微服務
市場上的分佈式鏈路追蹤⽅案
分佈式鏈路追蹤技術已然成熟，產品也很多，國內外都有，⽐如
Spring Cloud Sleuth + Twitter Zipkin
阿⾥巴巴的「鷹眼」
⼤衆點評的「CAT」
美團的「Mtrace」
京東的「Hydra」
新浪的「Watchman」
另外還有最近也被提到不少的Apache Skywalking。
性能
分佈式鏈路追蹤技術核⼼思想
本質：記錄⽇志，做爲⼀個完整的技術，分佈式鏈路追蹤也有⾃⼰的理論和概念
微服務架構中，針對請求處理的調⽤鏈能夠展示爲⼀棵樹，示意以下
上圖描述了⼀個常⻅的調⽤場景，⼀個請求經過⽹關服務路由到下游的微服務-1，而後微服務-1調⽤微服務-2，拿到結果後再調⽤微服務-3，最後組合微服務-2和微服務-3的結果，經過⽹關返回給⽤戶
爲了追蹤整個調⽤鏈路，確定須要記錄⽇志，⽇志記錄是基礎，在此之上確定有⼀些理論概念，當下主流的的分佈式鏈路追蹤技術/系統所基於的理念都來⾃於Google的⼀篇論⽂《Dapper, a Large-ScaleDistributed Systems Tracing Infrastructure》，這⾥⾯涉及到的核⼼理念是什麼，咱們來看下，還之前⾯的服務調⽤來講
上圖標識⼀個請求鏈路，⼀條鏈路經過TraceId惟⼀標識，span標識發起的請求信息，各span經過parrentId關聯起來
Trace：服務追蹤的追蹤單元是從客戶發起請求（request）抵達被追蹤系統的邊界開始，到被追蹤系統向客戶返回響應（response）爲⽌的過程
優化
Trace ID：爲了實現請求跟蹤，當請求發送到分佈式系統的⼊⼝端點時，只須要服務跟蹤框架爲該請求建立⼀個惟⼀的跟蹤標識Trace ID，同時在分佈式系統內部流轉的時候，框架失蹤保持該惟⼀標識，直到返回給請求⽅⼀個Trace由⼀個或者多個Span組成，每⼀個Span都有⼀個SpanId，Span中會記錄TraceId，同時還有⼀個叫作ParentId，指向了另外⼀個Span的SpanId，代表⽗⼦關係，其實本質表達了依賴關係spa
Span ID：爲了統計各處理單元的時間延遲，當請求到達各個服務組件時，也是經過⼀個惟⼀標識SpanID來標記它的開始，具體過程以及結束。對每⼀個Span來講，它必須有開始和結束兩個節點，經過記錄開始Span和結束Span的時間戳，就能統計出該Span的時間延遲，除了時間戳記錄以外，它還能夠包含⼀些其餘元數據，⽐如時間名稱、請求信息等架構設計
每⼀個Span都會有⼀個惟⼀跟蹤標識 Span ID,若⼲個有序的 span 就組成了⼀個 trace。
Span能夠認爲是⼀個⽇志數據結構，在⼀些特殊的時機點會記錄了⼀些⽇志信息，⽐若有時間戳、spanId、TraceId，parentIde等，Span中也抽象出了另外⼀個概念，叫作事件，核⼼事件以下
CS ：client send/start 客戶端/消費者發出⼀個請求，描述的是⼀個span開始
SR: server received/start 服務端/⽣產者接收請求 SR-CS屬於請求發送的⽹絡延遲
SS: server send/finish 服務端/⽣產者發送應答 SS-SR屬於服務端消耗時間
CR：client received/finished 客戶端/消費者接收應答 CR-SS表示回覆須要的時間(響應的⽹絡延遲)
Spring Cloud Sleuth （追蹤服務框架）能夠追蹤服務之間的調⽤，Sleuth能夠記錄⼀個服務請求通過哪些服務、服務處理時⻓等，根據這些，咱們可以理清各微服務間的調⽤關係及進⾏問題追蹤分析。
**耗時分析：**經過 Sleuth 瞭解採樣請求的耗時，分析服務性能問題（哪些服務調⽤⽐較耗時）
**鏈路優化：**發現頻繁調⽤的服務，針對性優化等
Sleuth就是經過記錄⽇志的⽅式來記錄蹤影數據的
注意：咱們每每把Spring Cloud Sleuth 和 Zipkin ⼀起使⽤，把 Sleuth 的數據信息發送給 Zipkin 進⾏聚合，利⽤ Zipkin 存儲並展現數據。