Spring Cloud Sleuth 之 Greenwich 版本全攻略

資料庫 SpringCloud · 發表 2019-02-12 10:29:58

摘要：點選上方“ 方誌朋”，選擇“置頂或者星標” 你的關注意義重大！微服務架構是一個分散式架構，微服務系統按業務劃分服務單元，一個微服務系統往往有很多個服務單元。由於服務單元數量眾多，業務的複雜性較高，如果出現了錯誤和異常，很難去定位。主要體現在一個請求可能需要呼叫很多個服務...

點選上方 “ 方誌朋 ”，選擇“置頂或者星標”

你的關注意義重大！

微服務架構是一個分散式架構，微服務系統按業務劃分服務單元，一個微服務系統往往有很多個服務單元。由於服務單元數量眾多，業務的複雜性較高，如果出現了錯誤和異常，很難去定位。主要體現在一個請求可能需要呼叫很多個服務，而內部服務的呼叫複雜性決定了問題難以定位。所以在微服務架構中，必須實現分散式鏈路追蹤，去跟進一個請求到底有哪些服務參與，參與的順序又是怎樣的，從而達到每個請求的步驟清晰可見，出了問題能夠快速定位的目的。

在微服務系統中，一個來自使用者的請求先到達前端A（如前端介面），然後通過遠端呼叫，到達系統的中介軟體B、C（如負載均衡、閘道器等），最後到達後端服務D、E，後端經過一系列的業務邏輯計算，最後將資料返回給使用者。對於這樣一個請求，經歷了這麼多個服務，怎麼樣將它的請求過程用資料記錄下來呢？這就需要用到服務鏈路追蹤。

Spring Cloud Sleuth

Spring Cloud Sleuth 為服務之間呼叫提供鏈路追蹤。通過 Sleuth 可以很清楚的瞭解到一個服務請求經過了哪些服務，每個服務處理花費了多長。從而讓我們可以很方便的理清各微服務間的呼叫關係。此外 Sleuth 可以幫助我們：

耗時分析: 通過 Sleuth 可以很方便的瞭解到每個取樣請求的耗時，從而分析出哪些服務呼叫比較耗時;
視覺化錯誤: 對於程式未捕捉的異常，可以通過整合 Zipkin 服務介面上看到;
鏈路優化: 對於呼叫比較頻繁的服務，可以針對這些服務實施一些優化措施。

Google開源了Dapper鏈路追蹤元件，並在2010年發表了論文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，這篇論文是業內實現鏈路追蹤的標杆和理論基礎，具有很高的參考價值。

Spring Cloud Sleuth採用了Google的開源專案Dapper的專業術語。

Span：基本工作單元，傳送一個遠端排程任務就會產生一個Span，Span是用一個64位ID唯一標識的，Trace是用另一個64位ID唯一標識的。Span還包含了其他的資訊，例如摘要、時間戳事件、Span的ID以及程序ID。
Trace：由一系列Span組成的，呈樹狀結構。請求一個微服務系統的API介面，這個API介面需要呼叫多個微服務單元，呼叫每個微服務單元都會產生一個新的Span，所有由這個請求產生的Span組成了這個Trace。
Annotation：用於記錄一個事件，一些核心註解用於定義一個請求的開始和結束，這些註解如下。

cs-Client Sent：客戶端傳送一個請求，這個註解描述了Span的開始。
sr-Server Received：服務端獲得請求並準備開始處理它，如果將其sr減去cs時間戳，便可得到網路傳輸的時間。
ss-Server Sent：服務端傳送響應，該註解表明請求處理的完成（當請求返回客戶端），用ss的時間戳減去sr時間戳，便可以得到伺服器請求的時間。
cr-Client Received：客戶端接收響應，此時Span結束，如果cr的時間戳減去cs時間戳，便可以得到整個請求所消耗的時間。

Spring Cloud Sleuth 也為我們提供了一套完整的鏈路解決方案,Spring Cloud Sleuth 可以結合 Zipkin，將資訊傳送到 Zipkin，利用 Zipkin 的儲存來儲存鏈路資訊，利用 Zipkin UI 來展示資料。

Zipkin

Zipkin是一種分散式鏈路追蹤系統。它有助於收集解決微服務架構中的延遲問題所需的時序資料。它管理這些資料的收集和查詢。 Zipkin的設計基於Google Dapper論文。

跟蹤器存在於應用程式中，記錄請求呼叫的時間和元資料。跟蹤器使用庫，它們的使用對使用者是無感知的。例如，Web伺服器會在收到請求時和傳送響應時會記錄相應的時間和一些元資料。一次完整鏈路請求所收集的資料被稱為Span。

我們可以使用它來收集各個伺服器上請求鏈路的跟蹤資料，並通過它提供的 REST API 介面來輔助我們查詢跟蹤資料以實現對分散式系統的監控程式，從而及時地發現系統中出現的延遲升高問題並找出系統性能瓶頸的根源。除了面向開發的 API 介面之外，它也提供了方便的 UI 元件來幫助我們直觀的搜尋跟蹤資訊和分析請求鏈路明細，比如：可以查詢某段時間內各使用者請求的處理時間等。 Zipkin 提供了可插拔資料儲存方式：In-Memory、MySql、Cassandra 以及 Elasticsearch。接下來的測試為方便直接採用 In-Memory 方式進行儲存，生產推薦 Elasticsearch.

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

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

案例實戰

在本案例一共有三個應用，分別為註冊中心，eureka-server、eureka-client、eureka-client-feign，三個應用的基本資訊如下：

應用名	埠	作用
eureka-server	8761	註冊中心
eureka-client	8763	服務提供者
eureka-client-feign	8765	服務消費者

其中eureka-server 應用為註冊中心，其他兩個應用向它註冊。eureka-client為服務提供者，提供了一個RESTAPI,eureka-client-feign為服務消費者，通過Feign Client向服務提供者消費服務。

在之前的文章已經講述瞭如何如何搭建服務註冊中心，在這裡就省略這一部分內容。服務提供者提供一個REST介面，服務消費者通過FeignClient消費服務。

服務提供者

eureka-client服務提供者，對外提供一個RESTAPI，並向服務註冊中心註冊，這部分內容，不再講述，見原始碼。需要在工程的pom檔案加上sleuth的起步依賴和zipkin的起步依賴，程式碼如下：

在工程的配置檔案application.yml需要做以下的配置：

其中spring.sleuth.web.client.enable為true設定的是web開啟sleuth功能;spring.sleuth.sampler.probability可以設定為小數，最大值為1.0，當設定為1.0時就是鏈路資料100%收集到zipkin-server，當設定為0.1時，即10%概率收集鏈路資料;spring.zipkin.base-url設定zipkin-server的地址。

對外提供一個Api，程式碼如下：

服務消費者

服務消費者通過FeignClient消費服務提供者提供的服務。同服務提供者一樣，需要在工程的pom檔案加上sleuth的起步依賴和zipkin的起步依賴，另外也需要在配置檔案application.yml做相關的配置，具體同服務提供者。

服務消費者通過feignClient進行服務消費，feignclient程式碼如下：

servcie層程式碼如下：

controller程式碼如下：

上面的程式碼對外暴露一個API，通過FeignClient的方式呼叫eureka-client的服務。

zipkin-server

在Spring Cloud D版本，zipkin-server通過引入依賴的方式構建工程，自從E版本之後，這一方式改變了，採用官方的jar形式啟動，所以需要通過下載官方的jar來啟動，也通過以下命令一鍵啟動：

上面的第一行命令會從zipkin官網下載官方的jar包。如果是window系統，建議使用gitbash執行上面的命令。

如果用 Docker 的話，使用以下命令：

通過java -jar zipkin.jar的方式啟動之後，在瀏覽器上訪問lcoalhost:9411，顯示的介面如下：

鏈路資料驗證

依次啟動eureka-server，eureka-client,eureka-client-feign的三個應用，等所有應用啟動完成後，在瀏覽器上訪問http://localhost:8765/hi（如果報錯，是服務與發現需要一定的時間，耐心等待幾十秒），訪問成功後，再次在瀏覽器上訪問zipkin-server的頁面，顯示如下：

從上圖可以看出每次請求所消耗的時間，以及一些span的資訊。

從上圖可以看出具體的服務依賴關係，eureka-feign-client依賴了eureka-client。

使用rabbitmq進行鏈路資料收集

在上面的案例中使用的http請求的方式將鏈路資料傳送給zipkin-server，其實還可以使用rabbitmq的方式進行服務的消費。使用rabbitmq需要安裝rabbitmq程式，下載地址http://www.rabbitmq.com/。

下載完成後，需要eureka-client和eureka-client-feign的起步依賴加上rabbitmq的依賴，依賴如下：

在配置檔案上需要配置rabbitmq的配置，配置資訊如下：

另外需要把spring.zipkin.base-url去掉。

在上面2個工程中，rabbitmq通過傳送鏈路資料，那麼zipkin-server是怎麼樣知道rabbitmq的地址呢，怎麼監聽收到的鏈路資料呢？這需要在程式啟動的時候，通過環境變數的形式到環境中，然後zikin-server從環境變數中讀取。可配置的屬性如下：

屬性	環境變數	描述
zipkin.collector.rabbitmq.addresses	RABBIT_ADDRESSES	用逗號分隔的 RabbitMQ 地址列表，例如localhost:5672,localhost:5673
zipkin.collector.rabbitmq.password	RABBIT_PASSWORD	連線到 RabbitMQ 時使用的密碼，預設為 guest
zipkin.collector.rabbitmq.username	RABBIT_USER	連線到 RabbitMQ 時使用的使用者名稱，預設為guest
zipkin.collector.rabbitmq.virtual-host	RABBIT VIRTUAL HOST	使用的 RabbitMQ virtual host，預設為 /
zipkin.collector.rabbitmq.use-ssl	RABBIT USE SSL	設定為true則用 SSL 的方式與 RabbitMQ 建立連結
zipkin.collector.rabbitmq.concurrency	RABBIT_CONCURRENCY	併發消費者數量，預設為1
zipkin.collector.rabbitmq.connection-timeout	RABBIT CONNECTION TIMEOUT	建立連線時的超時時間，預設為 60000毫秒，即 1 分鐘
zipkin.collector.rabbitmq.queue	RABBIT_QUEUE	從中獲取 span 資訊的佇列，預設為 zipkin

比如，通過以下命令啟動：

上面的命令等同於一下的命令：

用上面的2條命令中的任何一種方式重新啟動zipkin-server程式，並重新啟動eureka-client、eureka-server、eureka-client-feign，動完成後在瀏覽器上訪問http://localhost:8765/hi，再訪問http://localhost:9411/zipkin/，就可以看到通過Http方式傳送鏈路資料一樣的介面。

自定義Tag

在頁面上可以檢視每個請求的traceId，每個trace又包含若干的span，每個span又包含了很多的tag，自定義tag可以通過Tracer這個類來自定義。

將鏈路資料儲存在Mysql資料庫中

上面的例子是將鏈路資料存在記憶體中，只要zipkin-server重啟之後，之前的鏈路資料全部查詢不到了，zipkin是支援將鏈路資料儲存在mysql、cassandra、elasticsearch中的。現在講解如何將鏈路資料儲存在Mysql資料庫中。首先需要初始化zikin儲存在Mysql的資料的scheme，可以在這裡檢視https://github.com/openzipkin/zipkin/blob/master/zipkin-storage/mysql-v1/src/main/resources/mysql.sql，具體如下：

在資料庫中初始化上面的指令碼之後，需要做的就是zipkin-server如何連線資料庫。zipkin如何連資料庫同連線rabbitmq一樣。zipkin連線資料庫的屬性所對應的環境變數如下：

屬性	環境變數	描述
zipkin.torage.type	STORAGE_TYPE	預設的為mem，即為記憶體，其他可支援的為cassandra、cassandra3、elasticsearch、mysql
zipkin.torage.mysql.host	MYSQL_HOST	資料庫的host，預設localhost
zipkin.torage.mysql.port	MYSQL TCP PORT	資料庫的埠，預設3306
zipkin.torage.mysql.username	MYSQL_USER	連線資料庫的使用者名稱，預設為空
zipkin.torage.mysql.password	MYSQL_PASS	連線資料庫的密碼，預設為空
zipkin.torage.mysql.db	MYSQL_DB	zipkin使用的資料庫名，預設是zipkin
zipkin.torage.mysql.max-active	MYSQL MAX CONNECTIONS	最大連線數，預設是10

等同於以下的命令

使用上面的命令啟動zipkin.jar工程，然後再瀏覽數上訪問http://localhost:8765/hi，再訪問http://localhost:9411/zipkin/，可以看到鏈路資料。這時去資料庫檢視資料，也是可以看到儲存在資料庫的鏈路資料，如下：

這時重啟應用zipkin.jar，再次在瀏覽器上訪問http://localhost:9411/zipkin/，仍然可以得到之前的結果，證明鏈路資料儲存在資料庫中，而不是記憶體中。

將鏈路資料存在在Elasticsearch中

zipkin-server支援將鏈路資料儲存在ElasticSearch中。讀者需要自行安裝ElasticSearch和Kibana，下載地址為https://www. elastic.co/products/elasticsearch。安裝完成後啟動，其中ElasticSearch的預設埠號為9200，Kibana的預設埠號為5601。

同理，zipkin連線elasticsearch也是從環境變數中讀取的，elasticsearch相關的環境變數和對應的屬性如下：

屬性	環境變數	描述
zipkin.torage.elasticsearch.hosts	ES_HOSTS	ES_HOSTS，預設為空
zipkin.torage.elasticsearch.pipeline	ES_PIPELINE	ES_PIPELINE，預設為空
zipkin.torage.elasticsearch.max-requests	ES MAX REQUESTS	ES MAX REQUESTS，預設為64
zipkin.torage.elasticsearch.timeout	ES_TIMEOUT	ES_TIMEOUT，預設為10s
zipkin.torage.elasticsearch.index	ES_INDEX	ES_INDEX，預設是zipkin
zipkin.torage.elasticsearch.date-separator	ES DATE SEPARATOR	ES DATE SEPARATOR，預設為“-”
zipkin.torage.elasticsearch.index-shards	ES INDEX SHARDS	ES INDEX SHARDS，預設是5
zipkin.torage.elasticsearch.index-replicas	ES INDEX REPLICAS	ES INDEX REPLICAS，預設是1
zipkin.torage.elasticsearch.username	ES_USERNAME	ES的使用者名稱，預設為空
zipkin.torage.elasticsearch.password	ES_PASSWORD	ES的密碼，預設是為空

採用以下命令啟動zipkin-server:

啟動完成後，然後在瀏覽數上訪問http://localhost:8765/hi，再訪問http://localhost:9411/zipkin/，可以看到鏈路資料。這時鏈路資料儲存在ElasticSearch。

在zipkin上展示鏈路資料

鏈路資料儲存在ElasticSearch中，ElasticSearch可以和Kibana結合，將鏈路資料展示在Kibana上。安裝完成Kibana後啟動，Kibana預設會向本地埠為9200的ElasticSearch讀取資料。Kibana預設的埠為5601，訪問Kibana的主頁http://localhost:5601，其介面如下圖所示。

在上圖的介面中，單擊“Management”按鈕，然後單擊“Add New”，新增一個index。我們將在上節ElasticSearch中寫入鏈路資料的index配置為“zipkin”，那麼在介面填寫為“zipkin-*”，單擊“Create”按鈕，介面如下圖所示：

建立完成index後，單擊“Discover”，就可以在介面上展示鏈路資料了，展示介面如下圖所示。

參考資料

https://zipkin.io/

https://github.com/spring-cloud/spring-cloud-sleuth

https://cloud.spring.io/spring-cloud-static/spring-cloud-sleuth/2.1.0.RELEASE/single/spring-cloud-sleuth.html

https://github.com/openzipkin/zipkin/blob/master/zipkin-server/src/main/resources/zipkin-server-shared.yml

https://github.com/openzipkin/zipkin/blob/master/zipkin-storage/mysql-v1/src/main/resources/mysql.sql

https://windmt.com/2018/04/24/spring-cloud-12-sleuth-zipkin/

https://segmentfault.com/a/1190000015697673

http://www.cnblogs.com/JreeyQi/p/9336692.html

-更多文章-

MongoDB是個好東西，希望你也會

小說：白話冪等性設計

好文推薦，15 分鐘教你搞懂 Git！

Spring Cloud Greenwich版本已釋出！

-關注我-

看完了，幫我點個“好看”鴨

點鴨點鴨

↓↓↓↓