1. 分散式鏈路追蹤技術核⼼思想

下圖描述了⼀個常⻅的調⽤場景，⼀個請求通過⽹關服務路由到下游的微服務-1，然後微服務-1調⽤微服務-2，拿到結果後再調⽤微服務-3，最後組合微服務-2和微服務-3的結果，通過⽹關返回給⽤戶

上圖示識⼀個請求鏈路，⼀條鏈路通過TraceId唯⼀標識，span標識發起的請求資訊，各span通過parrentId關聯起來
Trace：服務追蹤的追蹤單元是從客戶發起請求（request）抵達被追蹤系統的邊界開始，到被追蹤系統向客戶返回響應（response）為⽌的過程
Trace ID：為了實現請求跟蹤，當請求傳送到分散式系統的⼊⼝端點時，只需要服務跟蹤框架為該請求建立⼀個唯⼀的跟蹤標識Trace ID，同時在分散式系統內部流轉的時候，框架失蹤保持該唯⼀標識，直到返回給請求⽅
⼀個Trace由⼀個或者多個Span組成，每⼀個Span都有⼀個SpanId，Span中會記錄TraceId，同時還有⼀個叫做ParentId，指向了另外⼀個Span的SpanId，表明⽗⼦關係，其實本質表達了依賴關係
Span ID：為了統計各處理單元的時間延遲，當請求到達各個服務元件時，也是通過⼀個唯⼀標識Span ID來標記它的開始，具體過程以及結束。對每⼀個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表示回覆需要的時間(響應的⽹絡延遲)

2.Spring Cloud Sleuth （追蹤服務框架）

可以追蹤服務之間的調⽤，Sleuth可以記錄⼀個服務請求經過哪些服務、服務處理時⻓等，根據這些，

我們能夠理清各微服務間的調⽤關係及進⾏問題追蹤分析。
耗時分析：通過 Sleuth 瞭解取樣請求的耗時，分析服務效能問題（哪些服務調⽤⽐較耗時）
鏈路優化：發現頻繁調⽤的服務，針對性優化等
Sleuth就是通過記錄⽇志的⽅式來記錄蹤跡資料的
注意：我們往往把Spring Cloud Sleuth 和 Zipkin ⼀起使⽤，把 Sleuth 的資料資訊傳送給 Zipkin 進⾏聚合，利⽤ Zipkin 儲存並展示資料。