Spring Cloud Sleuth和Zipkin的基本概念

    當服務服務化或者微服務進行管理後，服務子產品之前的調用拓撲非常的複雜。并且當每一個子產品又有多個分布式叢集等複雜的情況時，一個請求可能會調用後端的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）