科技

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

ElasticSearch SpringBoot SpringCloud · 發表 2018-11-07 19:25:00

摘要：線上演示演示地址： http://139.196.87.48:9002/kitty 使用者名稱：admin 密碼：admin 技術背景在微服務架構中，隨著業務發展，系統拆分導致系統呼叫鏈路愈發複雜，一個看似簡單的前端請求可能最終需要呼叫很多次後端服務才能完成，那麼當...

線上演示

演示地址： ofollow,noindex" target="_blank">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