大家好，我是瓜哥:

  最近公司打算啟用springcloud做微服務架構，微服務開發中鏈路跟蹤是很重要的一環，springcloud中zipkin就實現了鏈路跟蹤的整個功能，zipkin整合中使用到了kafka做鏈路資料收集，elasticsearch做資料儲存和搜尋，下面是整個呼叫過程。

Zipkin 是一款開源的分散式實時資料追蹤系統（Distributed Tracking System），基於 Google Dapper 的論文設計而來，由 Twitter公司開發貢獻。其主要功能是聚集來自各個異構系統的實時監控資料，用來追蹤微服務架構下的系統延時問題。應用系統需要進行裝備（instrument）以向 Zipkin 報告資料。Zipkin 的使用者介面可以呈現一幅關聯圖表，以顯示有多少被追蹤的請求通過了每一層應用。Zipkin 以 Trace 結構表示對一次請求的追蹤，又把每個 Trace 拆分為若干個有依賴關係的 Span。在微服務架構中，一次使用者請求可能會由後臺若干個服務負責處理，那麼每個處理請求的服務就可以理解為一個 Span（可以包括 API 服務，快取服務，資料庫服務以及報表服務等）。當然這個服務也可能繼續請求其他的服務，因此 Span 是一個樹形結構，以體現服務之間的呼叫關係。Zipkin 的使用者介面除了可以檢視 Span 的依賴關係之外，還以瀑布圖的形式顯示了每個 Span 的耗時情況，可以一目瞭然的看到各個服務的效能狀況。開啟每個 Span，還有更詳細的資料以鍵值對的形式呈現，而且這些資料可以在裝備應用的時候自行新增。

 可以看到zipkin內部主要分為四部分：collector、storage、api、ui

            collector：負責將各系統報告過來的追蹤資料進行接收

            storage：預設使用Cassandra儲存資料，也可以替換為其他儲存，例如mysql5.6-5.7，ElasticSearch 2.x和5.x，還有一些第三方的儲存

            api：查詢服務用來向其他服務提供資料查詢的能力，是以json api格式提供

            ui：Web服務是官方預設提供的一個圖形使用者介面