1、為什么用

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

鏈路追蹤組件有 Google 的 Dapper，Twitter 的 Zipkin，以及阿里的 Eagleeye （鷹眼）等，它 們都是非常優(yōu)秀的鏈路追蹤開源組件。

2、基本術語

? Span（跨度）：基本工作單元，發(fā)送一個遠程調(diào)度任務 就會產(chǎn)生一個 Span，Span 是一 個 64 位 ID 唯一標識的，Trace 是用另一個 64 位 ID 唯一標識的，Span 還有其他數(shù)據(jù)信 息，比如摘要、時間戳事件、Span 的 ID、以及進度 ID。

? Trace（跟蹤）：一系列 Span 組成的一個樹狀結構。請求一個微服務系統(tǒng)的 API 接口， 這個 API 接口，需要調(diào)用多個微服務，調(diào)用每個微服務都會產(chǎn)生一個新的 Span，所有 由這個請求產(chǎn)生的 Span 組成了這個 Trace。

? Annotation（標注）：用來及時記錄一個事件的，一些核心注解用來定義一個請求的開 始和結束 。這些注解包括以下：

????????? cs - Client Sent -客戶端發(fā)送一個請求，這個注解描述了這個 Span 的開始

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

????????? ss - Server Sent （服務端發(fā)送響應）–該注解表明請求處理的完成(當請求返回客戶? ? ? ? ? ?端)，如果 ss 的時間戳減去 sr 時間戳，就可以得到服務器請求的時間。

????????? cr - Client Received （客戶端接收響應）-此時 Span 的結束，如果 cr 的時間戳減? ?????????去cs 時間戳便可以得到整個請求所消耗的時間。

?官方文檔：

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

如果服務調(diào)用順序如下?

那么用以上概念完整的表示出來如下：?

Span 之間的父子關系如下：?

3、整合 Sleuth?

?1、服務提供者與消費者導入依賴

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

2、打開 debug 日志?

logging:level:org.springframework.cloud.openfeign: debugorg.springframework.cloud.sleuth: debug

3、發(fā)起一次遠程調(diào)用，觀察控制臺?

DEBUG [user-service,541450f08573fff5,541450f08573fff5,false] user-service：服務名

541450f08573fff5：是 TranceId，一條鏈路中，只有一個 T

ranceId 541450f08573fff5：是 spanId，鏈路中的基本工作單元 id

false：表示是否將數(shù)據(jù)輸出到其他服務，true 則會把信息輸出到其他可視化的服務上觀察

4、整合 zipkin 可視化觀察?

?通過 Sleuth 產(chǎn)生的調(diào)用鏈監(jiān)控信息，可以得知微服務之間的調(diào)用鏈路，但監(jiān)控信息只輸出 到控制臺不方便查看。我們需要一個圖形化的工具-zipkin。Zipkin 是 Twitter 開源的分布式跟 蹤系統(tǒng)，主要用來收集系統(tǒng)的時序數(shù)據(jù)，從而追蹤系統(tǒng)的調(diào)用問題。

zipkin 官網(wǎng)地址如下

https://zipkin.io/

1、docker 安裝 zipkin 服務器?

docker run -d -p 9411:9411 openzipkin/zipkin

2、pom導入?

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

zipkin 依賴也同時包含了 sleuth，可以省略 sleuth 的引用?

3、添加 zipkin 相關配置?

spring:application:name: user-servicezipkin:base-url: http://192.168.56.10:9411/ # zipkin 服務器的地址# 關閉服務發(fā)現(xiàn)，否則 Spring Cloud 會把 zipkin 的 url 當做服務名稱discoveryClientEnabled: falsesender:type: web # 設置使用 http 的方式傳輸數(shù)據(jù)sleuth:sampler:probability: 1 # 設置抽樣采集率為 100%，默認為 0.1，即 10%

發(fā)送遠程請求，測試 zipkin。?

服務調(diào)用鏈追蹤信息統(tǒng)計?

服務依賴信息統(tǒng)計?

5、Zipkin 數(shù)據(jù)持久化?

Zipkin 默認是將監(jiān)控數(shù)據(jù)存儲在內(nèi)存的，如果 Zipkin 掛掉或重啟的話，那么監(jiān)控數(shù)據(jù)就會丟 失。所以如果想要搭建生產(chǎn)可用的 Zipkin，就需要實現(xiàn)監(jiān)控數(shù)據(jù)的持久化。而想要實現(xiàn)數(shù)據(jù) 持久化，自然就是得將數(shù)據(jù)存儲至數(shù)據(jù)庫。好在 Zipkin 支持將數(shù)據(jù)存儲至：

? 內(nèi)存（默認）

? MySQL

? Elasticsearch

? Cassandra

Zipkin 數(shù)據(jù)持久化相關的官方文檔地址如下：?

https://github.com/openzipkin/zipkin#storage-componenthttps://github.com/openzipkin/zipkin#storage-component

Zipkin 支持的這幾種存儲方式中，內(nèi)存顯然是不適用于生產(chǎn)的，這一點開始也說了。而使用MySQL 的話，當數(shù)據(jù)量大時，查詢較為緩慢，也不建議使用。Twitter 官方使用的是 Cassandra作為 Zipkin 的存儲數(shù)據(jù)庫，但國內(nèi)大規(guī)模用 Cassandra 的公司較少，而且 Cassandra 相關文檔也不多。Zipkin-server不處理跟蹤數(shù)據(jù)的保留管理。使用ElasticSearch推薦的工具管理數(shù)據(jù)保留或群集 會無限增長！（這使用Elasticsearch 5 + 功能） 綜上，故采用 Elasticsearch 是個比較好的選擇，關于使用 Elasticsearch 作為 Zipkin 的存儲數(shù) 據(jù)庫的官方文檔如下：

elasticsearch-storage：

https://github.com/openzipkin/zipkin/tree/master/zipkin-server#elasticsearch-storagehttps://github.com/openzipkin/zipkin/tree/master/zipkin-server#elasticsearch-storagezipkin-storage/elasticsearch：

https://github.com/openzipkin/zipkin/tree/master/zipkin-storage/elasticsearchhttps://github.com/openzipkin/zipkin/tree/master/zipkin-storage/elasticsearch通過 docker 的方式：

docker run --env STORAGE_TYPE=elasticsearch --env ES_HOSTS=192.168.56.10:9200
openzipkin/zipkin-dependencies

?使用 es 時 Zipkin Dependencies 支持的環(huán)境變量