springcloud提供了服務跟蹤元件，用於分析各個微服務間的呼叫關係
一次微服務呼叫， 可能涉及多個微服務的呼叫。sleuth主要是通過在日誌中引入乙個id,來實現服務跟蹤的。
並且這個id有兩種型別，trace id和 span id
span id:代表工作的基本單元（如每次傳送的http請求）
trace id：是由多個span id組成的集合，是乙個樹狀的資料結構
第一步：工程引入pom
org.springframework.cloud
spring-cloud-starter-sleuth
在需要追蹤的方法中，加上日誌：
public listfindall()
控制台，觀察日誌：
2020-10-26 17:53:15.064 info [microservice-consumer-movie,ff7262d314c20aca,ff7262d314c20aca,false] 3564 --- [nio-8010-exec-4] c.i.c.s.user.controller.moviecontroller : findall---------------
2020-10-26 17:53:15.071 info [microservice-provider-user,ff7262d314c20aca,f2ac196501fcfb63,false] 7028 --- [nio-8005-exec-2] c.i.c.study.controller.usercontroller : 微服務生產者------------->
2.traceid：sleuth 為每個請求分配的id編號
3.spanid：乙個請求可以包含多個步驟，因此每個traceid可以有多個spanid
4.export：布林值，是否需要將該資訊輸出到聚合器中。
如果多個微服務都設定了日誌，就可以根據traceid和spanid的值，判斷這些方法是否在處理同乙個請求。
sleth不能追蹤thread執行緒，若需要追蹤，需要包裝原有的執行緒類：
整合多執行緒
步驟1：定義可跟蹤的執行緒服務@configuration
public class sleuththreadconfig
}
步驟2：引用（包裝過的）可跟蹤的執行緒類@autowired
executorservice executorservice;
sleuth:
baggage-keys:
#- baggageid
@component
public class mytracefilter extends genericfilterbean
}
分布式服務跟蹤Sleuth
作用 隨著業務的發展，系統規模也會變得越來越大，微服務間的呼叫關係也變得越來越錯綜複雜。通常由乙個客戶端發起的請求在後端系統中會經過多個不同的微服務呼叫來協同產生最後的請求結果，在複雜的微服務架構系統中，幾乎每乙個前端請求都會形成乙個複雜的分布式服務呼叫鏈路，在每條鏈路中任何乙個依賴服務出現延遲過高...
分布式服務跟蹤 Sleuth
sleuth是基於logback實現資料跟蹤的。在預設情況下，sleuth是基於日誌向控制台輸出跟蹤內容。不利於管理，統計，檢視，分析。在控制台中輸出跟蹤內容會嚴重影響系統效能。如果將跟蹤資料記錄在logback對應的日誌檔案中，也有問題 logback是分散的，是整合在每個服務應用中的，那麼日誌檔...
分布式服務跟蹤Sleuth
隨著業務的發展,系統規模也會變得越來越大,各微服務間的呼叫關係也變得越來越錯綜複雜。通常乙個由客戶端發起的請求在後端系統中會經過多個不同的微服務呼叫來協同產生最後的請求結果,在複雜的微服務架構系統中,幾乎每乙個前端請求都會形成一條複雜的分布式服務呼叫鏈路,在每條鏈路中任何乙個依賴服務出現延遲過高或錯...