隨著業務的發展,系統規模也會變得越來越大,各微服務間的呼叫關係也變得越來越錯綜複雜。通常乙個由客戶端發起的請求在後端系統中會經過多個不同的微服務呼叫來協同產生最後的請求結果,在複雜的微服務架構系統中,幾乎每乙個前端請求都會形成一條複雜的分布式服務呼叫鏈路,在每條鏈路中任何乙個依賴服務出現延遲過高或錯誤的時候都有可能引起請求最後的失敗。這時候, 對於每個請求,全鏈路呼叫的跟蹤就變得越來越重要,通過實現對請求呼叫的跟蹤可以幫助我們快速發現錯誤根源以及監控分析每條請求鏈路上的效能瓶頸等。
上面所述的分布式服務跟蹤問題, spring cloud sleuth提供了一套完整的解決方案，下面將介紹spring cloud sleuth的應用
1、為了保持其他模組的整潔性，重新搭建乙個消費者(springcloud-consumer-sleuth)，提供者(springcloud-consumer-sleuth)，消費者和提供者都是和前面所用的都一樣沒有什麼區別，註冊中心還是使用前面案例的註冊中心(springcloud-eureka-server/8700)，詳細檢視案例原始碼。
2、完成以上工作之後，我們為服務提供者和服務消費者新增跟蹤功能，通過spring cloud sleuth的封裝，我們為應用增加服務跟蹤能力的操作非常方便，只需要在服務提供者和服務消費者增加spring-cloud-starter-sleuth依賴即可
org.springframework.cloud3、訪問消費者介面，然後檢視控制台日誌顯示spring-cloud-starter-sleuth
消費者(springcloud-consumer-sleuth)列印的日誌
2019-12-05 12:30:20.178 info [springcloud-consumer-sleuth,f6fb983680aab32b,f6fb983680aab32b,false] 8992 --- [nio-9090-exec-1] c.s.controller.sleuthconsumercontroller : === consumer hello ===
提供者(springcloud-provider-sleuth)列印的日誌
2019-12-05 12:30:20.972 info [springcloud-provider-sleuth,f6fb983680aab32b,c70932279d3b3a54,false] 788 --- [nio-8080-exec-1] c.s.controller.sleuthprovidercontroller : === provider hello ===
從上面的控制台輸出內容中,我們可以看到多了一些形如 [springcloud-consumer-sleuth,f6fb983680aab32b,c70932279d3b3a54,false]的日誌資訊,而這些元素正是實現分布式服務跟蹤的重要組成部分,每個值的含義如下所述：
第二個值:f6fb983680aab32b, spring cloud sleuth生成的乙個id,稱為trace id, 它用來標識一條請求鏈路。一條請求鏈路中包含乙個trace id,多個span id
第三個值:c70932279d3b3a54, spring cloud sleuth生成的另外乙個id,稱為span id,它表示乙個基本的工作單元,比如傳送乙個http請求
第四個值: false,表示是否要將該資訊輸出到zipkin等服務中來收集和展示。上面四個值中的trace id和span id是spring cloud sleuth實現分布式服務跟蹤的核心，在一次服務請求鏈路的呼叫過程中,會保持並傳遞同乙個trace id,從而將整個分布於不同微服務程序中的請求跟蹤資訊串聯起來。以上面輸出內容為例springcloud-consumer-sleuth和springcloud-provider-sleuth同屬於乙個前端服務請求資源，所以他們的trace id是相同的，處於同一條請求鏈路中。
分布式系統中的服務跟蹤在理論上並不複雜,主要包括下面兩個關鍵點：
為了實現請求跟蹤,當請求傳送到分布式系統的入口端點時,只需要服務跟蹤框架為該請求建立乙個唯一的跟蹤標識,同時在分布式系統內部流轉的時候,框架始終保持傳遞該唯一標識,直到返回給請求方為止,這個唯一標識就是前文中提到的trace id。通過trace id的記錄,我們就能將所有請求過程的日誌關聯起來
為了統計各處理單元的時間延遲,當請求到達各個服務元件時,或是處理邏輯到達某個狀態時,也通過乙個唯一標識來標記它的開始、具體過程以及結束,該標識就是前面提到的span id。對於每個span來說,它必須有開始和結束兩個節點,通過記錄開始span和結束span的時間戳,就能統計出該span的時間延遲,除了時間 戳記錄之外,它還可以包含一些其他元資料,比如事件名稱、請求資訊等
在【二、sleuth快速入門】示例中,我們輕鬆實現了日誌級別的跟蹤資訊接入,這完全歸功於spring-cloud-starter-sleuth元件的實現，在springboot應用中通過在工程中引入spring-cloud-starter-sleuth依賴之後，他會自動為當前應用構建起各通訊通道的跟蹤機制，比如：
在【二、sleuth快速入門】示例中,由於springcloud-consumer-sleuth對springcloud-provider-sleuth發起的請求是通過resttemplate實現的,所以spring-cloud-starter-sleuth元件會對該請求進行處理。在傳送到springcloud-provider-sleuth之前,sleuth會在該請求的header中增加實現跟蹤需要的重要資訊,主要有下面這幾個(更多關於頭資訊的定義可以通過檢視org.springframework.cloud.sleuth.span的原始碼獲取)。
可以通過對springcloud-provider-sleuth的實現做一些修改來輸出這些頭資訊，具體如下：
}通過上面的改造，再次重啟案例，然後訪問我們檢視日誌，可以看到提供者輸出了正在處理的traceid和spanid資訊。
消費者(springcloud-consumer-sleuth)列印的日誌
2019-12-05 13:15:01.457 info [springcloud-consumer-sleuth,41697d7fa118c150,41697d7fa118c150,false] 10036 --- [nio-9090-exec-2] c.s.controller.sleuthconsumercontroller : === consumer hello ===
提供者(springcloud-provider-sleuth)列印的日誌
2019-12-05 13:15:01.865 info [springcloud-provider-sleuth,41697d7fa118c150,863a1245c86b580e,false] 11088 --- [nio-8080-exec-1] c.s.controller.sleuthprovidercontroller : === provider hello ===,traced=,spanid=
通過trace id和span id已經實現了對分布式系統中的請求跟蹤,而記錄的跟蹤資訊最終會被分析系統收集起來,並用來實現對分布式系統的監控和分析功能,比如,預警延遲過長的請求鏈路、查詢請求鏈路的呼叫明細等。此時,我們在對接分析系統時就會碰到個問題：分析系統在收集跟蹤資訊的時候,需要收集多少跟蹤資訊才合適呢？
理論上來說,我們收集的跟蹤資訊越多就可以越好地反映出系統的實際運**況,並給出更精準的預警和分析。但是在高併發的分布式系統執行時,大量的請求呼叫會產生海量的跟蹤日誌資訊，如果收集過多的跟蹤資訊將會對整個分布式系統的效能造成一定的影響，同時儲存大量的日誌資訊也需要不少的儲存開銷。所以，在sleuth中採用了抽象收集的方式來為跟蹤資訊打上收集標識，也就是我們之前在日誌資訊中看到的第4個布林型別的值，他代表了該資訊是否被後續的跟蹤資訊收集器獲取和儲存。
public abstract class sampler通過實現issampled方法, spring cloud sleuth會在產生跟蹤資訊的時候呼叫它來為跟蹤資訊生成是否要被收集的標誌。需要注意的是,即使issampled返回了false,它僅代表該跟蹤資訊不被輸出到後續對接的遠端分析系統(比如zipkin中,對於請求的跟蹤活動依然會進行,所以我們在日誌中還是能看到收集標識為fase的記錄。
spring:在開發除錯期間,通常會收集全部跟蹤資訊並輸出到遠端倉庫,我們可以將其值設定為1,或者也可以注入sampler物件samplerproperties策略,比如sleuth:
sampler:
probability: 0.1
@bean由於跟蹤日誌資訊資料的價值往往僅在最近一段時間內非常有用，比如一周。那麼我們在設計抽樣策略時，主要考慮在不對系統造成明顯效能影響的情況下，以在日誌保留時間窗內充分利用儲存空間的原則來實現抽樣策略。public sampler defaultsampler()
分布式服務跟蹤Sleuth
作用 隨著業務的發展，系統規模也會變得越來越大，微服務間的呼叫關係也變得越來越錯綜複雜。通常由乙個客戶端發起的請求在後端系統中會經過多個不同的微服務呼叫來協同產生最後的請求結果，在複雜的微服務架構系統中，幾乎每乙個前端請求都會形成乙個複雜的分布式服務呼叫鏈路，在每條鏈路中任何乙個依賴服務出現延遲過高...
分布式服務跟蹤 Sleuth
sleuth是基於logback實現資料跟蹤的。在預設情況下，sleuth是基於日誌向控制台輸出跟蹤內容。不利於管理，統計，檢視，分析。在控制台中輸出跟蹤內容會嚴重影響系統效能。如果將跟蹤資料記錄在logback對應的日誌檔案中，也有問題 logback是分散的，是整合在每個服務應用中的，那麼日誌檔...
sleuth服務跟蹤學習總結
springcloud提供了服務跟蹤元件，用於分析各個微服務間的呼叫關係 一次微服務呼叫，可能涉及多個微服務的呼叫。sleuth主要是通過在日誌中引入乙個id,來實現服務跟蹤的。並且這個id有兩種型別，trace id和 span id span id 代表工作的基本單元 如每次傳送的http請求 ...