Dubbox 鏈路追蹤（基於Brave+Zipkin的簡單實現）上
很多時候，我們都能體會到分散式架構的話好處，其實一個系統不大，做分散式的成本是很高的，系統變得鬆耦合，這樣做的好處不言而喻，說說壞處吧，A系統遠端呼叫B系統，B系統又依賴C,D系統，當線上某個介面報錯，或者超時的時候，亦或者是業務問題的時候，定位一個問題是麻煩的，因為日記不在一個系統裡面，排查問題的時候，需要花費很大的時間，往往定位問題的所在比解決這個問題花的時間長的多，所以解決這個問題，才會出來N多優秀的鏈路監控追蹤系統。
可惜，很多優秀的鏈路監控並沒有開源~
其實鏈路追蹤的實現的比較粗淺的理解（我的理解），其實就是前後filter，在filter中做埋點，記錄呼叫的時間，引數，異常，等等資訊，分散式系統需要多做的一件事就是有一個全域性的變數（全域性呼叫Id）來將整個呼叫鏈連線起來，形成呼叫閉環，最後最好再有一個視覺化的監控平臺，這樣就可以幫助我們去查詢問題的所在了。
5.2.1 簡介Zipkin
5.2.1.1 走進Zipkin
如果不借助任何的第三方的jar包，單純解決這種問題，還是比較困難的。簡單的說下開源的Zipkin,Zipkin官網：http://zipkin.io/
Zipkin是一個分散式追蹤系統，當我們在微服務架構中遇到潛在問題的時候，它會幫助我們按照時間的順序有規則的去收集資料，並且幫我們管理資料和查詢有用的資料，Zipkin是根據Google的論文Dapper設計的（dapper (dutch) = brave (english)）
Zipkin目的是用來記錄應用程式的時間資料日記的，Zipkin UI還提供了一個系統之間的呼叫依賴圖來向我們展示各個系統之間的請求鏈路關係，如果你遇到了一些bug或者系統報錯的時候，你可以使用
5.2.1.2 Zipkin 搭建
作為學習用，Zipkin的搭建還是很簡單的，它是預設使用記憶體做資料儲存的，當然它也支援Elasticsearch,Mysql等做資料儲存的，簡單地搭建作為學習用的話，使用記憶體就可以了，生產環境還是使用Elasticsearch比較好，mysql效能也是堪憂
點選Lastest release
下載好之後：
進入下載好的目錄,執行命令java-jar zipkin-server-1.19.1-exec.jar
因為是spring boot專案所以能夠直接啟動，瀏覽器開啟localhost:9411
這樣就完成了最簡單的基於記憶體的Zipkin的搭建了
5.2.1.3 Zipkin 簡單說明
Zipkin的簡單設計原理圖：
上圖中，Instrumented client 目標服務消費者，如果它是需要進行鏈路導航的，它會在呼叫的時候，它會將在呼叫服務的時候，把一些引數通過Transport傳遞給Zipkin，同樣當服務提供者接收到呼叫者的請求的時候，也會得到呼叫的上下文，也會把呼叫的資訊，返回的資訊形成Reporter通過Transport傳遞給Zipkin，相反，如果某些服務沒有開啟導航功能，則不會發出Reporter，Zipkin通過資訊收集器（Collector）獲取到資訊之後，進行儲存，然後形成呼叫查詢的API,供UI頁面查詢。
用大白話說，就是在遠端呼叫的時候，服務消費者和服務提供者如果需要進行鏈路追蹤，需要把呼叫的資訊通過某個東西的傳輸給Zipkin，Zipkin幫忙分析記錄你的呼叫過程。
Zipkin的資料設計和細節簡單說明：
之前說過，Zipkin可以把分散式系統呼叫的日記集中在一起做分析處理，幫我們在遠端調用出問題的時候，快速的定位問題，設計的簡單思路就是類似那種filter，在特定的時候，進行資料攔擊記錄，然後形成固定的格式資料傳送給Zipkin做處理。
考慮一下細節,與具體的使用場景進行結合，比如Dubbo，使用Dubbo在進行遠端呼叫的時候，服務消費者在呼叫的時候，這個階段Zipkin定義為CS
CS表示客戶端開啟，客戶端開始請求，在這個階段也會設定span
當請求通過網路到達服務提供者的時候，便達到了第二個階段，Zipkin稱之為SR
SR表示服務端接收，當服務提供者接收到請求的時候，將會去處理這個請求，這個階段與上一個階段其實是有上下文連線的，（CS可以在呼叫的上下文偷偷放置一個全域性的TraceId）,當然這個階段與上個階段會有網路延遲和時間間隔
當服務提供者處理好請求準備返回的時候，到了第三個階段SS
SS表示服務端傳送請求，這個階段表示服務端已經完成了請求的處理，然後準備把請求的結果傳送回客戶端，當然SS與SR之間在時間的維度上的區別就是多了服務消費者的處理時間
當返回結果通過網路達到服務消費者端的時候，就達到了第四階段CR
CR表示客戶端接收，當服務消費者接收到服務提供者的響應的時候，這就是表示了Span的結束了，經歷了四個階段，表示整個RPC的呼叫流程完成了，並且也會被這四個階段記錄.
5.2.1.4 Zipkin的幾個重要的概念：
上文說有四個階段，其實在分散式中，這四個階段其實是在不同的系統中的，如果你想把這四個階段連線在一起，也是經過處理的，打個比方，這四個節點就像四個珠子，如果你想把這四個珠子串聯起來，還需要一條線：
線的定義（TraceId），鏈路ID，整個呼叫流程在CS階段會形成一個鏈路ID,接下來的三個階段公用整個TraceId
珠子的定義（span），每一個珠子都有一個模型叫做span，也有它的唯一標識SpanId，那麼對於Span物件來說，它肯定知道自己上一個珠子的id（ParentId），自己的Id（SpanId）,整個鏈路的Id（TraceId）
5.2.1.5 Zipkin 小節
本小節簡單地介紹了Zipkin的幾個概念，還有一些細節，不是很好理解，比如Sampled, Flags等等，這些概念在使我們接下來的使用過程中會有些接觸，接觸到了，程式碼擼出來了，估計也會理解了。