Spring Boot + Spring Cloud 實現權限管理系統 後端篇（二十二）：鏈路追蹤（Sleuth、Zipkin）

在線演示

演示地址：http://139.196.87.48:9002/kitty

用戶名：admin 密碼：admin

技術背景

在微服務架構中，隨着業務發展，系統拆分致使系統調用鏈路愈發複雜，一個看似簡單的前端請求可能最終須要調用不少次後端服務才能完成，那麼當整個請求出現問題時，咱們很可貴知究竟是哪一個服務出了問題致使的，這時就須要解決一個問題，如何快速定位服務故障點，因而，分佈式系統調用鏈追蹤技術就此誕生了。

ZipKin

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

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

Zipkin提供了可插拔數據存儲方式：In-Memory、MySql、Cassandra以及Elasticsearch。咱們能夠跟根據需求選擇不一樣的存儲方式，生成環境通常都須要持久化。咱們這裏採用elasticsearch做爲zipkin的數據存儲器。

Spring Cloud Sleuth

通常而言，一個分佈式服務追蹤系統，主要有三部分組成：數據收集、數據存儲和數據展現。

Spring Cloud Sleuth爲服務之間的調用提供鏈路追蹤，經過Sleuth能夠很清楚的瞭解到一個服務請求通過了哪些服務，每一個服務處理花費了多長。從而讓咱們能夠很方便的理清各微服務間的調用關係。此外，Sleuth還能夠幫助咱們：

耗時分析: 經過Sleuth能夠很方便的瞭解到每一個採樣請求的耗時，從而分析出哪些服務調用比較耗時。

可視化錯誤: 對於程序未捕捉的異常，能夠經過集成Zipkin服務界面上看到。

鏈路優化: 對於調用比較頻繁的服務，能夠針對這些服務實施一些優化措施。

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

實現案例

在早前的Spring Cloud版本里是須要自建zipkin服務端的，可是從SpringCloud2.0 之後，官方已經不支持自建Server了，改爲提供編譯好的jar包供用戶使用。由於我用的是2.0之後的版本，自建Servcer的方式請自行百度。這裏咱們是使用docker方式部署zipkin服務，並採用elasticsearch做爲zipkin的數據存儲器。

下載鏡像

此前請先安裝好docker環境，使用如下命令分別拉取zipkin和elasticsearch鏡像。

docker pull openzipkin/zipkin
docker pull docker.elastic.co/elasticsearch/elasticsearch:6.3.0

經過 docker images 查看下載鏡像。

編寫啓動文件

在本地建立以下文件夾結構， data目錄用來存放elasticsearch存儲的數據。

dockerfile
    |- elasticsearch
    |    |- data
    |- docker-compose.yml

編寫docker-compose文件，主要做用是批量啓動容器，避免在使用多個容器的時候逐個啓動的繁瑣。

docker-compose.yml

version: "3"
services:

  elasticsearch:
    image:  docker.elastic.co/elasticsearch/elasticsearch:6.3.0
    container_name: elasticsearch
    restart: always
    networks:
      - elk
    ports:
      - "9200:9200"
      - "9300:9300"
    volumes:
       - ../elasticsearch/data:/usr/share/elasticsearch/data

  zipkin:
    image: openzipkin/zipkin:latest
    container_name: zipkin
    restart: always
    networks:
      - elk
    ports:
      - "9411:9411"
    environment:
      - STORAGE_TYPE=elasticsearch
      - ES_HOSTS=elasticsearch

networks:
    elk:

關於docker-compose.yml 文件格式及相關內容請自行百度瞭解。

啓動服務

命令模式進入dockerfile目錄，執行啓動命令以下。

docker-compose up -d

執行過程以下圖所示。

執行完成以後，經過 docker ps 命令查看，發現zipkin和elasticsearch確實啓動起來了。

到這裏，zipkin服務端就搭建起來了，訪問 http://localhost:9411，效果以下，由於尚未客戶端，因此尚未數據。

注意：

這裏咱們採用了elasticsearch做爲存儲方式，若是想簡單經過內存方式啓動，無須安裝elasticsearch，直接啓動一個zipkin容器便可。

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

若是想使用其餘如數據庫等方式存儲，請查詢相關配置文檔。

zipkin服務端已經搭建完成了，接下來咱們來實現客戶端。

添加依賴

修改 kitty-consumer 項目Maven配置，添加zipkin依賴。

pom.xml

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

配置文件

修改配置文件，添加以下zipkin配置。

spring:
  zipkin:
    base-url: http://localhost:9411/
  sleuth:
    sampler:
      probability: 1 #樣本採集量，默認爲0.1，爲了測試這裏修改成1，正式環境通常使用默認值。

application.yml

server:
  port: 8005
spring:
  application:
    name: kitty-consumer
  cloud:
    consul:
      host: localhost
      port: 8500
      discovery:
        serviceName: ${spring.application.name}    # 註冊到consul的服務名稱
  boot:
    admin:
      client:
        url: "http://localhost:8000"
  zipkin:
    base-url: http://localhost:9411/
  sleuth:
    sampler:
      probability: 1 #樣本採集量，默認爲0.1，爲了測試這裏修改成1，正式環境通常使用默認值。
# 開放健康檢查接口
management:
  endpoints:
    web:
      exposure:
        include: "*"
  endpoint:
    health:
      show-details: ALWAYS
#開啓熔斷器
feign:
  hystrix:
    enabled: true

測試效果

前後啓動註冊中心、服務監控、服務提供者、服務消費者。

反覆訪問幾回 http://localhost:8005/feign/call，產生zipkin數據。

 

再次訪問 http://localhost:9411， 發現出現了咱們剛剛訪問的服務，選擇並點擊追蹤。

點擊追蹤以後，頁面顯示了相關的服務調用信息。 

 

點擊調用記錄查看詳情頁面，能夠看到每個服務所耗費的時間和順序。

 

源碼下載

後端：https://gitee.com/liuge1988/kitty

前端：https://gitee.com/liuge1988/kitty-ui.git

---

做者：朝雨憶輕塵
出處：https://www.cnblogs.com/xifengxiaoma/ 版權全部，歡迎轉載，轉載請註明原文做者及出處。