快捷導(dǎo)航

SpringCloud集成Sleuth和Zipkin的思路講解

更新時(shí)間：2022年11月02日 14:06:14 作者：Hahahahahahaha~

Zipkin 是 Twitter 的一個(gè)開源項(xiàng)目，它基于 Google Dapper 實(shí)現(xiàn)，它致力于收集服務(wù)的定時(shí)數(shù)據(jù)，以及解決微服務(wù)架構(gòu)中的延遲問題，包括數(shù)據(jù)的收集、存儲(chǔ)、查找和展現(xiàn)，這篇文章主要介紹了SpringCloud集成Sleuth和Zipkin,需要的朋友可以參考下

組件說明

Zipkin

Zipkin 是 Twitter 的一個(gè)開源項(xiàng)目，它基于 Google Dapper 實(shí)現(xiàn)，它致力于收集服務(wù)的定時(shí)數(shù)據(jù)，以及解決微服務(wù)架構(gòu)中的延遲問題，包括數(shù)據(jù)的收集、存儲(chǔ)、查找和展現(xiàn)。

sleuth

sleuth是一個(gè)工具，它在整個(gè)分布式系統(tǒng)中能跟蹤一個(gè)用戶請(qǐng)求的過程(包括數(shù)據(jù)采集，數(shù)據(jù)傳輸，數(shù)據(jù)存儲(chǔ)，數(shù)據(jù)分析，數(shù)據(jù)可視化)，捕獲這些跟蹤數(shù)據(jù)，就能構(gòu)建微服務(wù)的整個(gè)調(diào)用鏈的視圖，這是調(diào)試和監(jiān)控微服務(wù)的關(guān)鍵工具

微服務(wù)架構(gòu)是一個(gè)分布式架構(gòu)，它按業(yè)務(wù)劃分服務(wù)單元，一個(gè)分布式系統(tǒng)往往有很多個(gè)服務(wù)單元。由于服務(wù)單元數(shù)量眾多，業(yè)務(wù)的復(fù)雜性，如果出現(xiàn)了錯(cuò)誤和異常，很難去定位 。主要體現(xiàn)在，一個(gè)請(qǐng)求可能需要調(diào)用很多個(gè)服務(wù) ，而內(nèi)部服務(wù)的調(diào)用復(fù)雜性，決定了問題難以定位。所以微服務(wù)架構(gòu)中，必須實(shí)現(xiàn)分布式鏈路追蹤，去跟進(jìn)一個(gè)請(qǐng)求到底有哪些服務(wù)參與，參與的順序又是怎樣的，從而達(dá)到每個(gè)請(qǐng)求的步驟清晰可見，出了問題，很快定位 。

基本術(shù)語(yǔ)

Span （跨度）：基本工作單元，發(fā)送一個(gè)遠(yuǎn)程調(diào)度任務(wù) 就會(huì)產(chǎn)生一個(gè) Span ， Span 是一個(gè) 64 位 ID 唯一標(biāo)識(shí)的， Trace 是用另一個(gè) 64 位 ID 唯一標(biāo)識(shí)的， Span 還有其他數(shù)據(jù)信息，比如摘要、時(shí)間戳事件、Span 的 ID 、以及進(jìn)度 ID 。
Trace （跟蹤）：一系列 Span 組成的一個(gè)樹狀結(jié)構(gòu)。請(qǐng)求一個(gè)微服務(wù)系統(tǒng)的 API 接口，這個(gè) API 接口，需要調(diào)用多個(gè)微服務(wù)，調(diào)用每個(gè)微服務(wù)都會(huì)產(chǎn)生一個(gè)新的 Span ，所有由這個(gè)請(qǐng)求產(chǎn)生的 Span 組成了這個(gè) Trace 。
Annotation （標(biāo)注）：用來及時(shí)記錄一個(gè)事件的，一些核心注解用來定義一個(gè)請(qǐng)求的開始和結(jié)束。這些注解包括以下：
cs - Client Sent - 客戶端發(fā)送一個(gè)請(qǐng)求，這個(gè)注解描述了這個(gè) Span 的開始
sr - Server Received - 服務(wù)端獲得請(qǐng)求并準(zhǔn)備開始處理它，如果將其 sr 減去 cs 時(shí)間戳便可得到網(wǎng)絡(luò)傳輸?shù)臅r(shí)間。
ss - Server Sent （服務(wù)端發(fā)送響應(yīng)） – 該注解表明請(qǐng)求處理的完成 ( 當(dāng)請(qǐng)求返回客戶端) ，如果 ss 的時(shí)間戳減去 sr 時(shí)間戳，就可以得到服務(wù)器請(qǐng)求的時(shí)間。
cr - Client Received （客戶端接收響應(yīng)） - 此時(shí) Span 的結(jié)束，如果 cr 的時(shí)間戳減去cs 時(shí)間戳便可以得到整個(gè)請(qǐng)求所消耗的時(shí)間
Sleuth配合ZIPKIN的使用

所有服務(wù)都加入以下依賴：

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-sleuth</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zipkin</artifactId>
        </dependency>

使用docker安裝zipkin：docker run -d -p 9411:9411 openzipkin/zipkin

所有微服務(wù)加入以下配置：

#服務(wù)追蹤，url填自己的服務(wù)器地址
spring.zipkin.base-url=http://192.168.56.10:9411/
#關(guān)閉服務(wù)發(fā)現(xiàn)
spring.zipkin.discovery-client-enabled=false
spring.zipkin.sender.type=web
#配置采樣器
spring.sleuth.sampler.probability=1

啟動(dòng)服務(wù)，進(jìn)行一系列業(yè)務(wù)操作，再進(jìn)入配置中輸入的url：http://192.168.56.10:9411/

Zipkin 數(shù)據(jù)持久化

Zipkin 默認(rèn)是將監(jiān)控?cái)?shù)據(jù)存儲(chǔ)在內(nèi)存的，如果 Zipkin 掛掉或重啟的話，那么監(jiān)控?cái)?shù)據(jù)就會(huì)丟失。所以如果想要搭建生產(chǎn)可用的 Zipkin，就需要實(shí)現(xiàn)監(jiān)控?cái)?shù)據(jù)的持久化。數(shù)據(jù)可以存到內(nèi)存，mysql，elasticsearch和Cassandra中。 Zipkin 支持的這幾種存儲(chǔ)方式中，內(nèi)存顯然是不適用于生產(chǎn)的。而使用 MySQL 的話，當(dāng)數(shù)據(jù)量大時(shí)，查詢較為緩慢，也不建議使用。 Twitter 官方使用的是 Cassandra作為 Zipkin 的存儲(chǔ)數(shù)據(jù)庫(kù)，但國(guó)內(nèi)用 Cassandra 的公司較少，而且 Cassandra 相關(guān)文檔也不多。綜上，故采用 Elasticsearch 是個(gè)比較好的選擇。使用docker進(jìn)行配置（前提已經(jīng)安裝了Elasticsearch）： docker run --env STORAGE_TYPE=elasticsearch --env ES_HOSTS=192.168.56.10:9200 openzipkin/zipkin-dependencies 附：使用 es 時(shí) Zipkin Dependencies 支持的環(huán)境變量