本文節選自《瘋狂Spring Cloud微服務架構實戰》html
京東購買地址:https://item.jd.com/12256011.htmlgit
噹噹網購買地址:http://product.dangdang.com/25201393.html服務器
Spring Cloud教學視頻:https://my.oschina.net/JavaLaw/blog/1552993架構
Spring Cloud電子書:https://my.oschina.net/JavaLaw/blog/1570383app
先對微服務跟蹤的相關概念,作一個基本的講解。框架
前面章節中,咱們使用Spring Cloud來搭建服務集羣,不管是Eureka服務器、服務實例,仍是配置服務器、網關等節點,均可以橫向擴展。一旦集羣中的服務數量增多,而且它們之間存在複雜的依賴關係,那麼管理它們將會變成一件很棘手的事情。分佈式
當外部用戶向集羣發起請求,這些請求將會調用多個服務,每一個服務又會依賴其餘的服務,此時,若是出現異常、超時等狀況,排查問題將變得很是困難。咱們須要很清楚知道,服務出現了什麼問題,這些問題出在哪一個環節。微服務
爲了能解決這些問題,Spring Cloud提供了Sleuth框架做爲解決方案,Sleuth能夠與Zipkin、Apache HTrace和ELK等數據分析、服務跟蹤系統進行整合,爲服務跟蹤、解決問題提供了便利。測試
目前有許多的分佈式跟蹤系統,例如Zipkin、HTrace等,這些系統能夠幫助咱們收集一些,由服務實時產生的數據(主要是日誌),經過這些數據能夠分析出分佈式系統的健康狀態、服務調用過程、調用耗時等指標,爲優化系統、解決問題提供了依據。優化
讀者須要區別兩個基本的概念:服務跟蹤和數據分析,數據分析系統(例如ELK等)收集了服務集羣所產生的數據後,也能夠實現服務監控、服務跟蹤等功能,但明顯數據分析系統的概念更爲普遍、抽象。本書將會介紹服務跟蹤系統Zipkin,一樣也會介紹著名的數據分析平臺ELK。
Sleuth借鑑了Google Dapper的設計,先了解如下兩個概念:
圖10-1簡單地描述了跨度的概念。
圖10-1 跨度
如圖10-1,用戶或外部程序調用A服務,這次調用看做是跨度A,A服務還要調用B服務,在跨度A的基礎上會產生跨度B,跨度B是跨度A的一部分,在Sleuth的設計上,跨度A是B的父跨度。所以在整個跟蹤過程當中,這些跨度是樹狀結構的。
除了跟蹤和跨度外,還要了解一下Annotation(事件標識),它主要用於記錄事件的存在,主要包括如下幾個事件標識:
在使用Sleuth前,先準備本章的測試項目,本章主要以一個微服務集羣爲基礎,該集羣包括如下項目:
以上的項目,都可以在codes\10目錄找到對應的源碼,幾個項目的結構請見圖10-2。
圖10-2 測試項目結構
以上幾個測試項目是一個簡單的Spring Cloud集羣,銷售服務依賴了「圖書服務」和「支付服務」。
本文節選自《瘋狂Spring Cloud微服務架構實戰》
Spring Cloud教學視頻:https://my.oschina.net/JavaLaw/blog/1552993
Spring Cloud電子書:https://my.oschina.net/JavaLaw/blog/1570383
本書代碼共享地址:https://gitee.com/yangenxiong/SpringCloud