Zipkin是什麼
Zipkin分散式跟蹤系統；它可以幫助收集時間資料，解決在microservice架構下的延遲問題；它管理這些資料的收集和查詢；Zipkin的設計是基於谷歌的Google Dapper論文。願意瞭解原始碼的朋友直接求求交流分享技術：二一四七七七五六三三

每個應用程式向Zipkin報告定時資料，Zipkin UI呈現了一個依賴圖表來展示多少跟蹤請求經過了每個應用程式；如果想解決延遲問題，可以過濾或者排序所有的跟蹤請求，並且可以檢視每個跟蹤請求佔總跟蹤時間的百分比。

為什麼使用Zipkin
隨著業務越來越複雜，系統也隨之進行各種拆分，特別是隨著微服務架構和容器技術的興起，看似簡單的一個應用，後臺可能有幾十個甚至幾百個服務在支撐；一個前端的請求可能需要多次的服務呼叫最後才能完成；當請求變慢或者不可用時，我們無法得知是哪個後臺服務引起的，這時就需要解決如何快速定位服務故障點，Zipkin分散式跟蹤系統就能很好的解決這樣的問題。

Zipkin原理

針對服務化應用全鏈路追蹤的問題，Google發表了Dapper論文，介紹了他們如何進行服務追蹤分析。其基本思路是在服務呼叫的請求和響應中加入ID，標明上下游請求的關係。利用這些資訊，可以視覺化地分析服務呼叫鏈路和服務間的依賴關係。

對應Dpper的開源實現是Zipkin，支援多種語言包括JavaScript，Python，Java, Scala, Ruby, C#, Go等。其中Java由多種不同的庫來支援

Spring Cloud Sleuth是對Zipkin的一個封裝，對於Span、Trace等資訊的生成、接入HTTP Request，以及向Zipkin Server傳送採集資訊等全部自動完成。Spring Cloud Sleuth的概念圖見上圖。

Zipkin架構

跟蹤器(Tracer)位於你的應用程式中，並記錄發生的操作的時間和元資料,提供了相應的類庫，對使用者的使用來說是透明的，收集的跟蹤資料稱為Span;將資料傳送到Zipkin的儀器化應用程式中的元件稱為Reporter,Reporter通過幾種傳輸方式之一將追蹤資料傳送到Zipkin收集器(collector)，然後將跟蹤資料進行儲存(storage),由API查詢儲存以向UI提供資料。
架構圖如下：

.

1.Trace
Zipkin使用Trace結構表示對一次請求的跟蹤，一次請求可能由後臺的若干服務負責處理，每個服務的處理是一個Span，Span之間有依賴關係，Trace就是樹結構的Span集合；

2.Span
每個服務的處理跟蹤是一個Span，可以理解為一個基本的工作單元，包含了一些描述資訊：id，parentId，name，timestamp，duration，annotations等。

3.Transport
收集的Spans必須從被追蹤的服務運輸到Zipkin collector，有三個主要的傳輸方式：HTTP, Kafka和Scribe；

4.Components
有4個元件組成Zipkin：collector，storage，search，web UI
collector：一旦跟蹤資料到達Zipkin collector守護程序，它將被驗證，儲存和索引，以供Zipkin收集器查詢；
storage：Zipkin最初資料儲存在Cassandra上，因為Cassandra是可擴充套件的，具有靈活的模式，並在Twitter中大量使用；但是這個元件可插入，除了Cassandra之外，還支援ElasticSearch和MySQL；  儲存，zipkin預設的儲存方式為in-memory，即不會進行持久化操作。如果想進行收集資料的持久化，可以儲存資料在Cassandra，因為Cassandra是可擴充套件的，有一個靈活的模式，並且在Twitter中被大量使用，我們使這個元件可插入。除了Cassandra，我們原生支援ElasticSearch和MySQL。其他後端可能作為第三方擴充套件提供。
search：一旦資料被儲存和索引，我們需要一種方法來提取它。查詢守護程序提供了一個簡單的JSON API來查詢和檢索跟蹤，主要給Web UI使用；
web UI：建立了一個GUI，為檢視痕跡提供了一個很好的介面；Web UI提供了一種基於服務，時間和註釋檢視跟蹤的方法。

整體程式碼結構如下：