微服務調用鏈追蹤中心搭建

　概述

一個完整的微服務系統包含多個微服務單元，各個微服務子系統存在互相調用的情況，形成一個調用鏈。一個客戶端請求從發出到被響應經歷了哪些組件、哪些微服務、請求總時長、每個組件所花時長等信息我們有必要了解和收集，以幫助我們定位性能瓶頸、進行性能調優，因此監控整個微服務架構的調用鏈十分有必要，本文將闡述如何使用Zipkin搭建微服務調用鏈追蹤中心。

正如 Ziplin官網所描述，Zipkin是一款分散式的追蹤系統，其可以幫助我們收集微服務架構中用於解決延時問題的時序數據，更直白地講就是可以幫我們追蹤調用的軌跡。

Zipkin的設計架構如下圖所示：

要理解這張圖，需要了解一下Zipkin的幾個核心概念：

Reporter

在某個應用中安插的用於發送數據給Zipkin的組件稱為Report，目的就是用於追蹤數據收集

Span

微服務中調用一個組件時，從發出請求開始到被響應的過程會持續一段時間，將這段跨度稱為Span

Trace

從Client發出請求到完成請求處理，中間會經歷一個調用鏈，將這一個整個過程稱為一個追蹤（Trace）。一個Trace可能包含多個Span，反之每個Span都有一個上級的Trace。

Transport

一種數據傳輸的方式，比如最簡單的HTTP方式，當然在高並發時可以換成Kafka等消息隊列

看了一下基本概念後，再結合上面的架構圖，可以試著理解一下，只有裝配有Report組件的Client才能通過Transport來向Zipkin發送追蹤數據。追蹤數據由Collector收集器進行手機然後持久化到Storage之中。最後需要數據的一方，可以通過UI界面調用API介面，從而最終取到Storage中的數據。可見整體流程不複雜。

Zipkin官網給出了各種常見語言支持的OpenZipkin libraries：

本文接下來將構造微服務追蹤的實驗場景並使用Brave來輔助完成微服務調用鏈追蹤中心搭建！

利用Docker來部署Zipkin服務再簡單不過了：

完成之後瀏覽器打開：可以看到Zipkin的可視化界面：

我們來構造一個如下圖所示的調用鏈：

圖中包含一個客戶端+三個微服務：

Client：使用/servicea介面消費ServiceA提供的服務

ServiceA：使用/serviceb介面消費ServiceB提供的服務，埠8881

ServiceB：使用/servicec介面消費ServiceC提供的服務，埠8882

ServiceC：提供終極服務，埠8883

為了模擬明顯的延時效果，準備在每個介面的響應中用代碼加入3s的延時。

簡單起見，我們用SpringBt來實現三個微服務。

ServiceA的控制器代碼如下：

ServiceB的代碼如下：

ServiceC的代碼如下：

我們將三個微服務都啟動起來，然後瀏覽器中輸入來發出請求，過了9s之後，將取到ServiceC中提供的微服務介面所返回的內容，如下圖所示：

很明顯，調用鏈可以正常work了！

那麼接下來我們就要引入Zipkin來追蹤這個調用鏈的信息！

從Zipkin官網我們可以知道，藉助OpenZipkin庫Brave，我們可以開發一個封裝Brave的公共組件，讓其能十分方便地嵌入到ServiceA，ServiceB，ServiceC服務之中，完成與Zipkin的通信。

為此我們需要建立一個新的基於Maven的Java項目：

pom.xml中加入如下依賴：

編寫ZipkinProperties類

其包含endpoint和service兩個屬性，我們最後是需要將該兩個參數提供給ServiceA、ServiceB、ServiceC微服務作為其application.properties中的Zipkin配置

用了lombok之後，這個類異常簡單！

編寫ZipkinConfiguration類

這個類很重要，在裡面我們將Brave的BraveClientHttpRequestInterceptor攔截器註冊到RestTemplate的攔截器調用鏈中來收集請求數據到Zipkin中；同時還將Brave的ServletHandlerInterceptor攔截器註冊到調用鏈中來收集響應數據到Zipkin中

上代碼吧：

ZipkinTool完成以後，我們需要在ServiceA、ServiceB、ServiceC三個SpringBt項目的application.properties中加入Zipkin的配置：

以ServiceA為例：

我們最後依次啟動ServiceA、ServiceB、和ServiceC三個微服務，並開始實驗來收集鏈路追蹤數據！

瀏覽器打開Zipkin的UI界面，可以查看依賴分析：