[菜鳥SpringCloud實戰入門]第十章：分佈式鏈路跟蹤 Sleuth和Zipkin

時間 2019-12-05

標籤菜鳥 springcloud 實戰入門第十分佈式鏈路跟蹤 sleuth zipkin 欄目系統架構简体版

原文原文鏈接

前言

歡迎來到菜鳥SpringCloud實戰入門系列(SpringCloudForNoob)，該系列經過層層遞進的實戰視角，來一步步學習和理解SpringCloud。html

本系列適合有必定Java以及SpringBoot基礎的同窗閱讀。前端

每篇文章末尾都附有本文對應的Github源代碼，方便同窗調試。java

Github倉庫地址：git

github.com/qqxx6661/sp…github

菜鳥SpringCloud實戰入門系列

你能夠經過如下兩種途徑查看菜鳥SpringCloud實戰入門系列：web

關注個人公衆號：Rude3Knife 點擊公衆號下方：技術推文——SpringCloud
菜鳥SpringCloud實戰入門專欄導航頁(CSDN)

前文回顧：算法

實戰版本

SpringBoot：2.0.3.RELEASE
SpringCloud：Finchley.RELEASE

-----正文開始-----

分佈式鏈路跟蹤 Sleuth和Zipkin

分佈式鏈路跟蹤介紹

對於一個微服務系統，大多數來自外部的請求都會通過數個服務的互相調用，獲得返回的結果，一旦結果回覆較慢或者返回了不可用，咱們就須要肯定是哪一個微服務出了問題。因而就有了分佈式系統調用跟蹤的誕生。spring

現今業界分佈式服務跟蹤的理論基礎主要來自於 Google 的一篇論文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，使用最爲普遍的開源實現是 Twitter 的 Zipkin，爲了實現平臺無關、廠商無關的分佈式服務跟蹤，CNCF 發佈了布式服務跟蹤標準 Open Tracing。國內，淘寶的「鷹眼」、京東的「Hydra」、大衆點評的「CAT」、新浪的「Watchman」、惟品會的「Microscope」、窩窩網的「Tracing」都是這樣的系統。docker

Spring Cloud Sleuth 介紹

通常的，一個分佈式服務跟蹤系統，主要有三部分：數據收集、數據存儲和數據展現。根據系統大小不一樣，每一部分的結構又有必定變化。譬如，對於大規模分佈式系統，數據存儲可分爲實時數據和全量數據兩部分，實時數據用於故障排查（troubleshooting），全量數據用於系統優化；數據收集除了支持平臺無關和開發語言無關係統的數據收集，還包括異步數據收集（須要跟蹤隊列中的消息，保證調用的連貫性），以及確保更小的侵入性；數據展現又涉及到數據挖掘和分析。雖然每一部分均可能變得很複雜，但基本原理都相似。後端

Spring Cloud Sleuth爲服務之間調用提供鏈路追蹤。Sleuth能夠幫助咱們：

耗時分析: 經過Sleuth能夠很方便的瞭解到每一個採樣請求的耗時，從而分析出哪些服務調用比較耗時;
可視化錯誤: 對於程序未捕捉的異常，能夠經過集成Zipkin服務界面上看到;
鏈路優化: 對於調用比較頻繁的服務，能夠針對這些服務實施一些優化措施。

Spring Cloud Sleuth的概念圖：

trace:從客戶發起請求（request）抵達被追蹤系統的邊界開始，到被追蹤系統向客戶返回響應（response）爲止的過程.包含一系列的span，它們組成了一個樹型結構
span: 每一個 trace中會調用若干個服務，爲了記錄調用了哪些服務，以及每次調用的消耗時間等信息，在每次調用服務時，埋入一個調用記錄，稱爲一個「span」。Span是基本的工做單元。Span包括一個64位的惟一ID，一個64位trace碼，描述信息，時間戳事件，key-value 註解(tags)，span處理者的ID（一般爲IP）。最開始的初始Span稱爲根span，此span中span id和 trace id值相同。
Annotation: 用於及時記錄存在的事件。經常使用的Annotation以下
- cs - Client Sent：客戶端發送一個請求，表示span的開始
- sr - Server Received：服務端接收請求並開始處理它。(sr-cs)等於網絡的延遲
- ss - Server Sent：服務端處理請求完成，開始返回結束給服務端。(ss-sr)表示服務端處理請求的時間
- cr - Client Received：客戶端完成接受返回結果，此時span結束。(cr-sr)表示客戶端接收服務端數據的時間

ZipKin介紹

spring cloud sleuth能夠結合zipkin，將信息發送到zipkin，利用zipkin的存儲來存儲信息，利用zipkin ui來展現數據。

Zipkin 是一個開放源代碼分佈式的跟蹤系統，由Twitter公司開源，它致力於收集服務的定時數據，以解決微服務架構中的延遲問題，包括數據的收集、存儲、查找和展示。

每一個服務向zipkin報告計時數據，zipkin會根據調用關係經過Zipkin UI生成依賴關係圖，顯示了多少跟蹤請求經過每一個服務，該系統讓開發者可經過一個 Web 前端輕鬆的收集和分析數據，例如用戶每次請求服務的處理時間等，可方便的監測系統中存在的瓶頸。

Zipkin提供了可插拔數據存儲方式：In-Memory、MySql、Cassandra以及Elasticsearch。接下來的測試爲方便直接採用In-Memory方式進行存儲，生產推薦Elasticsearch。

spring cloud sleuth結合zipkin

在使用 Spring Boot 2.x 版本後，官方就不推薦自行定製編譯了，讓咱們直接使用編譯好的 jar 包.也就是說原來經過@EnableZipkinServer或@EnableZipkinStreamServer的路子，啓動SpringBootApplication自建Zipkin Server是不行了

安裝和部署zipkin

官方提供了一鍵腳本

curl -sSL https://zipkin.io/quickstart.sh | bash -s
java -jar zipkin.jar
複製代碼

若是用 Docker 的話，直接

docker run -d -p 9411:9411 openzipkin/zipkin
複製代碼

我使用腳本的方法，在IDEA的terminal裏運行java -jar zipkin.jar

訪問 http://localhost:9411/zipkin/ ：

修改service-feign和eureka-hi模塊設置

接下來咱們須要建造一串調用，咱們使用以前的模塊service-feign和eureka-hi

修改子模塊eureka-hi和service-feign的pom文件：

添加三個依賴：

<!--分佈式鏈路追蹤-->
<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>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
</dependency>
複製代碼

修改子模塊eureka-hi和service-feign的yml配置文件,添加相關配置：

spring:
    sleuth:
        web:
          client:
            enabled: true
        sampler:
          probability: 1.0 # 將採樣比例設置爲 1.0，也就是所有都須要。默認是 0.1
      zipkin:
        base-url: http://localhost:9411/ # 指定了 Zipkin 服務器的地址
複製代碼

Spring Cloud Sleuth 有一個 Sampler 策略，能夠經過這個實現類來控制採樣算法。採樣器不會阻礙 span 相關 id 的產生，可是會對導出以及附加事件標籤的相關操做形成影響。 Sleuth 默認採樣算法的實現是 Reservoir sampling，具體的實現類是 PercentageBasedSampler，默認的採樣比例爲: 0.1(即 10%)。不過咱們能夠經過spring.sleuth.sampler.percentage來設置，所設置的值介於 0.0 到 1.0 之間，1.0 則表示所有采集。

至此，一切就緒。Spring 應用在監測到 classpath 中有 Sleuth 和 Zipkin 後，會自動在 WebClient（或 RestTemplate）的調用過程當中向 HTTP 請求注入追蹤信息，並向 Zipkin Server 發送這些信息。