SpringCloud集成Sleuth和Zipkin的思路講解

第SpringCloud集成Sleuth和Zipkin的思路講解目錄組件說明Zipkinsleuth基本術(shù)語Zipkin數(shù)據(jù)持久化

組件說明

Zipkin

Zipkin是Twitter的一個(gè)開源項(xiàng)目，它基于GoogleDapper實(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ù)語

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-ClientSent-客戶端發(fā)送一個(gè)請(qǐng)求，這個(gè)注解描述了這個(gè)Span的開始

sr-ServerReceived-服務(wù)端獲得請(qǐng)求并準(zhǔn)備開始處理它，如果將其sr減去cs時(shí)間戳便可得到網(wǎng)絡(luò)傳輸?shù)臅r(shí)間。

ss-ServerSent（服務(wù)端發(fā)送響應(yīng)）該注解表明請(qǐng)求處理的完成(當(dāng)請(qǐng)求返回客戶端)，如果ss的時(shí)間戳減去sr時(shí)間戳，就可以得到服務(wù)器請(qǐng)求的時(shí)間。

cr-ClientReceived（客戶端接收響應(yīng)）-此時(shí)Span的結(jié)束，如果cr的時(shí)間戳減去cs時(shí)間戳便可以得到整個(gè)請(qǐng)求所消耗的時(shí)間

Sleuth配合ZIPKIN的使用

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

dependency

groupIdorg.springframework.cloud/groupId

artifactIdspring-cloud-starter-sleuth/artifactId

/dependency

dependency

groupIdorg.springframework.cloud/groupId

artifactIdspring-cloud-starter-zipkin/artifactId

/dependency

使用docker安裝zipkin：dockerrun-d-p9411:9411openzipkin/zipkin

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

#服務(wù)追蹤，url填自己的服務(wù)器地址

spring.zipkin.base-url=0:9411/

#關(guān)閉服務(wù)發(fā)現(xiàn)

spring.zipkin.discovery-client-enabled=false

spring.zipkin.sender.type=web

#配置采樣器

bability=1

啟動(dòng)服務(wù)，進(jìn)行一系列業(yè)務(wù)操作，再進(jìn)入配置中輸入的url：0: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ù)庫，但國內(nèi)用Cassandra的公司較少，而且Cassandra相關(guān)文檔也不多。綜上，故采用Elasticsearch是個(gè)比較好的選擇。使用docker進(jìn)行配置（前提已經(jīng)安裝了Elasticsearch）：dockerrun--envSTORAG