java B2B2C電子商務平臺分析之十三-----Spring Cloud Zipkin

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提供了一種基於服務，時間和註釋查看跟蹤的方法。

總體代碼結構以下：