當服務服務化或者微服務進行管理後，服務模塊之前的調用拓撲非常的複雜。並且當每一個模塊又有多個分佈式集羣等複雜的情況時，一個請求可能會調用後端的N多臺服務，那麼在追查問題的時候是非常麻煩的。一般不同的小組會負責不同的服務模塊，則跨團隊的協作是非常麻煩的。比如電商平臺中，當一個請求進入後，api網關會根據URI會分發到不同的服務模塊，比如當前調用到了訂單系統，訂單系統可能會去查下商品系統。我們原來的商品系統會根據業務分爲好幾個子系統，有的子系統還有自己的服務模塊，總共商品有上百臺服務器。那麼在問題追蹤的時候可以想象。。。（那麼服務鏈路追蹤太重要了）
一、常見的業界開源解決方案
1、Dapper（谷歌）
2、Zikpin（騰訊），與Spring Cloud Sleuth結合的比較好
3、Eagleeye（阿里）
4、pinpoint
5、skywalking
二、服務追蹤原理
1、Trace
由一組Trace Id相同的Span串聯形成一個樹狀結構。爲了實現請求跟蹤，當請求到達分佈式系統的入口端點時，只需要服務跟蹤框架爲該請求創建一個唯一的標識（即TraceId），同時在分佈式系統內部流轉的時候，框架始終保持傳遞該唯一值，直到整個請求的返回。那麼我們就可以使用該唯一標識將所有的請求串聯起來，形成一條完整的請求鏈路。
2、Span
代表了一組基本的工作單元。爲了統計各處理單元的延遲，當請求到達各個服務組件的時候，也通過一個唯一標識（SpanId）來標記它的開始、具體過程和結束。通過SpanId的開始和結束時間戳，就能統計該span的調用時間，除此之外，我們還可以獲取如事件的名稱。請求信息等元數據。
3、Annotation
用它記錄一段時間內的事件，內部使用的重要註釋：
cs（Client Send）客戶端發出請求，開始一個請求的生命
sr（Server Received）服務端接受到請求開始進行處理， timestampSR - timestampCS = 網絡延遲（服務調用的時間）
ss（Server Send）服務端處理完畢準備發送到客戶端， timestampSS - timestampSR = 服務器上的請求處理時間
cr（Client Reveived）客戶端接受到服務端的響應，請求結束。 timestampCR - timestampCS = 請求的總時間
三、重要概念
1、spring-cloud-sleuth-zipkin + spring-cloud-starter-sleuth 就相當於直接引入 spring-cloud-starter-zipkin
2、配置
spring.zipkin.enabled=true # 啓用
spring.zipkin.base-url=http://127.0.0.1:9411/ # sleuth默認爲上報爲false， 現設置上報zipkin的服務地址
spring.sleuth.sampler.probability = 1 # span的採樣率，默認爲 0.1
spring.sleuth.sampler.rate = 10000 # 爲了使用速率限制採樣器，請設置spring.sleuth.sampler.rate屬性以選擇每秒間隔 # 接受的trace量，最小數字爲0，最大值爲2,147,483,647（最大int）