3二、Spring Cloud 服務跟蹤總結

喜歡關注公衆號： java樂園

上兩篇講解了zipkin，這篇總結一下。其實Spring Cloud實施分佈式跟蹤解決方案所用的技術不單單是zipkin。在spring官網：
http://spring.io/projects/spring-cloud-sleuth
有這麼一段話：

翻譯過來：
Spring Cloud Sleuth是Spring Cloud實施分佈式跟蹤解決方案，大量借用Dapper，Zipkin和HTrace。 對於大多數用戶來講，偵探應該是隱形的，而且全部與外部系統的交互都應該自動進行檢測。 您能夠簡單地在日誌中捕獲數據，也能夠將數據發送到遠程收集器服務。
Spring Cloud Sleuth借用了Dapper的術語：
 跨度（Span）：基本的工做單位。例如，發送一個RPC是一個新的跨度，就像向RPC發送響應同樣。跨度由跨度的惟一64位ID和跨度所包含的另外一個 64位ID標識。Spans還具備其餘數據，例如描述，時間戳事件，鍵值註釋（標記），致使它們的跨度的ID以及進程ID（一般爲IP地址）。跨度啓動和中止，並跟蹤他們的時間信息。一旦你建立了一個跨度，你必須在未來某個時候中止它。開始追蹤的初始跨度被稱爲 root span。該跨度的span id的值等於trace id。

 痕跡（Trace）：一組造成樹狀結構的跨度。例如，若是您正在運行分佈式大數據存儲，則跟蹤可能由放入請求組成。

  標註（Annotation）：用於及時記錄事件的存在。用於定義請求開始和結束的一些核心註釋是：
cs - 客戶端發送 - 客戶端發出請求。這個註釋描述了跨度的開始。
sr - 服務器已收到 - 服務器端收到請求並開始處理。若是從這個時間戳中減去cs時間戳，將會收到網絡延遲。
ss - 服務器發送 - 在請求處理完成時（當響應被髮送回客戶端時）註釋。若是從這個時間戳中減去sr時間戳，將會收到服務器端處理請求所需的時間。
cr - 客戶端收到 - 表示跨度結束。客戶端已經成功接收到服務器端的響應。若是從這個時間戳中減去cs時間戳，那麼將會收到客戶端接收服務器響應所需的所有時間。

Span和Trace在系統中與Zipkin Annotation一塊兒顯示的可視化示例：
（https://github.com/spring-cloud/spring-cloud-sleuth）

一、依賴說明
從中央倉庫https://mvnrepository.com能夠查詢到如下與zipkin和sleuth相關的jar引用：spring-cloud-starter-zipkin、spring-cloud-starter-sleuth、spring-cloud-sleuth-zipkin，他們只有有什麼關係呢？

從pom.xml的引用關係能夠看到spring-cloud-starter-zipkin包含了spring-cloud-starter-sleuth和spring-cloud-sleuth-zipkin，就是所引入spring-cloud-starter-zipkin就等於引用了spring-cloud-starter-sleuth和spring-cloud-sleuth-zipkin

二、配置說明
Zipkin和Sleuth配置類分別是：
Zipkin： org.springframework.cloud.sleuth.zipkin2.ZipkinProperties
Sleuth： org.springframework.cloud.sleuth.autoconfig.SleuthProperties
從這兩個類就能夠知道Zipkin和Sleuth分別有哪些配置項

三、分佈式服務跟蹤系統原理
分佈式服務跟蹤系統，主要有三部分：數據收集、數據存儲和數據展現。根據系統大小不一樣，每一部分的結構又有必定變化。譬如對於大規模分佈式系統，數據存儲可分爲實時數據和全量數據兩部分，實時數據用於故障排查（trouble shooting），全量數據用於系統優化；數據收集除了支持平臺無關和開發語言無關係統的數據收集，還包括異步數據收集（須要跟蹤隊列中的消息，保證調用的連貫性），以及確保更小的侵入性；數據展現又涉及到數據挖掘和分析。雖然每一部分均可能變得很複雜，但基本原理都相似。
阿里雲的一些服務能夠類比，好比你須要收集一臺雲主機的IO狀況，CPU使用率、磁盤使用狀況等；就須要在咱們的雲主機安裝一個代理agent（類比Zipkin Client），這個代理agent的做用就是收集當前主機的數據，而後上送到管理控制檯（類比Zipkin Server）