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/ 
版權所有,歡迎轉載,轉載請注明原文作者及出處。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM