1. 程式人生 > 其它 >基於 Zipkin的鏈路追蹤

基於 Zipkin的鏈路追蹤

Zipkin介紹:

Zipkin 是 Twitter 的一個開源專案,它基於 Google Dapper 實現,它致力於收集服務的定時資料,

以 解決微服務架構中的延遲問題,包括資料的收集、儲存、查詢和展現。 我們可以使用它來收集各個伺服器

上請求鏈路的跟蹤資料,並通過它提供的 REST API 介面來輔助我們查詢跟蹤資料以實現對分散式系 統的監控程式,

從而及時地發現系統中出現的延遲升高問題並找出系統性能瓶頸的根源。除了面向開發 的 API 介面之外,

它也提供了方便的 UI 元件來幫助我們直觀的搜尋跟蹤資訊和分析請求鏈路明細,比 如:可以查詢某段時間內各使用者

請求的處理時間等。 Zipkin 提供了可插拔資料儲存方式:In-Memory、  

MySql、Cassandra 以及 Elasticsearch。

 

上圖展示了 Zipkin 的基礎架構,它主要由 4 個核心元件構成:

  • Collector:收集器元件,它主要用於處理從外部系統傳送過來的跟蹤資訊,將這些資訊轉換為Zipkin 內部處理的 Span 格式,以支援後續的儲存、分析、展示等功能。
  • Storage:儲存元件,它主要對處理收集器接收到的跟蹤資訊,預設會將這些資訊儲存在記憶體中,我們也可以修改此儲存策略,通過使用其他儲存元件將跟蹤資訊儲存到資料庫中。
  • RESTful API:API 元件,它主要用來提供外部訪問介面。比如給客戶端展示跟蹤資訊,或是外接系統訪問以實現監控等。
  • Web UI:UI 元件,基於 API 元件實現的上層應用。通過 UI 元件使用者可以方便而有直觀地查詢和分析跟蹤資訊。 

Zipkin 分為兩端,一個是 Zipkin 服務端,一個是 Zipkin 客戶端,客戶端也就是微服務的應用。

客戶端會配置服務端的 URL 地址,一旦發生服務間的呼叫的時候,會被配置在微服務裡面的 Sleuth 的監聽器監聽,並生成相應的 Trace 和 Span 資訊傳送給服務端。

傳送的方式主要有兩種,一種是 HTTP 報文的方式,還有一種是訊息匯流排的方式如 RabbitMQ

 

不論哪種方式,我們都需要:   1.一個 Eureka 服務註冊中心,這裡我們就用之前的 eureka 專案來當註冊中心。
  2.一個 Zipkin 服務端   3.多個微服務,這些微服務中配置Zipkin 客戶端。