SpringCloud 微服務 (十六) 服務追蹤 Zipkin

問題

在服務中,有一個接口,該A接口中又調用了其餘服務的B、C、D接口,出現一個請求耗時大的問題,這時候並不知道該B、C、D接口中哪一個接口形成的耗時量,而後好比肯定C服務接口出現的耗時量大,可是C服務又是另個開發人員負責,通知他你的接口耗時大,因而他就去看代碼,可能他的C接口又包含着D服務接口,光想着就以爲這個套路怎麼這麼噁心,老是須要解決的問題,靠日誌輸出打點方式查看某個接口的耗時也以爲low,不方便,逐步學習研究,Spring Cloud提供了相關的組件Sleuth來優化以上問題,下面作個學習筆記

 

鏈路監控 Spring Cloud Sleuth

sleuth 翻譯是偵察的意思,學習了以後sleuth操做的點很少,重點在偵察,就是怎麼看指標信息

maven引入依賴,結束

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

再來訪問一個服務中的接口,在控制檯以sleuth方式打印出相關的信息,格式以下:

...INFO [product,84189hh321,h32eh823,false] 25612-[xxxxx] xxxxx

第一個product爲服務的名字

第二個TraceId, 一條鏈路的惟一標識,好比A中包含BCD接口,那麼請求A時,BCD中出現的TraceId都一致

第三個SpanId,一個基本單元,一條鏈路請求中能夠包含多個Spanid,能夠理解成基本的工做元素,好比一個請求

第四個false,那確定會有true,該鏈路的信息是否要輸出到其餘服務進行展現

 

服務之間使用feign進行通訊,給feign加上日誌級別,配置yml

logging:
  level:
    org.springframework.cloud.netflix.feign: debug

spring cloud正式版本配置feign的包路徑有所不一樣,以下

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

 

配置完了以後,每次請求都會打印出日誌信息在控制檯

 

仍是在控制檯看,這樣總很差,須要一個友好的控制檯一類的監控窗口,找到了一個工具---Zipkin

 

Zipkin

大多數組件的官網都是以io結尾,好比zipkin的官網地址:zipkin.io。 spring的官網地址: spring.io

在左側邊欄的Quickstart中,有說明幾種使用方式,這邊使用docker方式

不得不說這個鏡像下的很吃力,試了屢次才搞定,並運行他

訪問一下: http://localhost:9411,出現下面界面就是成功了,功於docker

這是一個展現臺,還須要將服務連上zipkin,繼續套路,在maven中加入依賴

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

spring-cloud-starter-zipkin包含spring-cloud-starter-sleuth和spring-cloud-sleuth-zipkin,因此使用一個就能夠,以前測試的刪掉

配置yml,向zipkin展現信息,配置完就能夠訪問接口,在zipkin就會有相關信息

spring:
  zipkin:
    base-url: http://localhost:9411
  sleuth:
    sampler:
      probability: 1
      percentage: 1
//傻辦法,若是選一個,沒法暴露調用鏈,就換一個試試[probability,percentage]

在開發環境下probability能夠設置爲1,正式環境設置1會佔帶寬,流量,切記,提示一下這個配置名字官方換過一次,有的叫percentage,都是同樣的,一個是概率的意思,一個是百分比的意思,按本身的springcloud版原本設置便可

到信息臺了,就是點點點,看看看,你們都會,就很少說明了

 

分佈式追蹤系統

核心步驟 通常有三個: 

1. 數據採集
2. 數據存儲
3. 查詢展現

在數據採集過程當中,因爲不一樣服務的API並非徹底兼容的,這就引發若是但願切換追蹤系統,每每會有較大改動,就出現了一個OpenTracing規範,爲解決不一樣分佈式系統API不兼容的問題

OpenTracing的優點: 提供與平臺無關、廠商無關的API,使開發人員更容易入手操做,好比更換追蹤系統的實現

行業俗話: 一流的作標準,二流的作平臺,三流的作產品

有一些產品都跟進OpenTracing標準,好比有zipkin、tracer、jaeger、grpc等等

OpenTracing的重要的概念Trace就是調用鏈,是經過歸屬該調用鏈的Span來定義,Trace和Span源自Google的開源項目,叫作Dapper的專業術語,還有一個術語叫Annotation,看着很熟悉,是用來即時記錄一個事件,一些核心註解用來定義一個請求的開始和結束,能夠理解成是Span生命週期的頭尾快照,包含發生時間,事件類型等信息,事件類型有如下四種 :

• cs (Client Send) : 客戶端發起請求的時間
• cr (Client Received) : 客戶端收處處理完請求的時間
• ss (Server Send) : 服務端處理完邏輯的時間
• sr (Server Received) : 服務端收到調用端請求的時間

從以上能夠簡單的歸納,其將請求的生命週期轉化成四種類型,最終計算時間減一下就得出來了 

客戶端調用時間= cr - cs

服務端調用時間= sr - ss

 

在官網閒逛,發現一張圖,幫助學習分析 Zipkin

這圖是Zipkin的架構圖,綠色部分是Zipkin四個核心的組件: Collector,Storage,API,UI;

Collector是收集組件,用於處理從外部系統發送過來的跟蹤信息,而後將信息轉化成能夠內部處理的Span格式,用於後續的存儲、分析、展現

Storage是儲存,默認存在內存中,若是服務從新啓動會清空歷史數據,若是須要持久化儲存數據,須要修改儲存策略,能夠存到Mysql、ES等地方

API是提供給外部訪問的restful接口,好比給客戶端展現跟蹤信息,外部訪問實現監控等等

UI是基於API實現的上層應用,經過該組件直觀的查詢跟蹤信息,以前也測試過了,在頁面上很方便的查詢請求的各類信息,服務之間的依賴關係

 

微服務每每作着作着就愈來愈大,服務之間的關係也是從線條到網狀結構,搞不清誰和誰有關係,這樣從請求鏈中能夠直觀的體現

 

就學到這邊,忽然意識到Spring Cloud主要組件彷佛已經所有走了一遍了,雞凍,知新而溫故,串着的走一套,加油

---------------------------------------------------------------