導讀
微服務架構中，是否遇到過這種情況，服務間呼叫鏈過長，導致性能遲遲上不去，不知道哪里出問題了，巴拉巴拉....，回歸正題，今天我們使用SpringCloud組件，來分析一下微服務架構中系統呼叫的瓶頸問題~
SpringCloud鏈路追蹤組件Sleuth實戰
官網
主要功能：做日志埋點
什么是Sleuth
專門用于追蹤每個請求的完整呼叫鏈路，
例如：【order-service,f674cc8202579a50,4727309367e0b514,false】
-
- 第一個值：spring.application.name
- 第二個值，sleuth生成的一個ID，交Trace ID，用來標識一條請求鏈路，一條請求鏈路中包含一個Trace ID，多個Span ID
- 第三個值：spanid基本的作業單元，獲取元資料，如發送一個http請求
- 第四個值：false，是否要將該資訊輸出到zipkin服務中來收集和展示
添加依賴
牽扯到的服務都得加這個依賴！(我這里是在order-service、product-service加的依賴)
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-sleuth</artifactId> </dependency>
啟動整個微服務測驗
部署可視化鏈路追蹤Zipkin
簡介
大規模分布式系統的APM工具，基于Google Dapper的基礎實作，和Sleuth結合可以提供可視化web界面分析呼叫鏈路耗時情況，
官網
點我直達
部署
點我直達
這里我使用下載原始碼的方式
# get the latest source
git clone https://github.com/openzipkin/zipkin
cd zipkin
# Build the server and also make its dependencies
./mvnw -DskipTests --also-make -pl zipkin-server clean install
# Run the server
java -jar ./zipkin-server/target/zipkin-server-*exec.jar
備注
因為種種原因，從github上下載這個原始碼包，非常慢，可以使用這種方式解決：點我直達
git clone https://gitee.com/mirrors/zipkin.git
cd zipkin
mvn -DskipTests clean package
java -jar ./zipkin-server/target/zipkin-server-*exec.jar
啟動
地址：ip:9411
Zpikin+Sleuth整合
添加依賴
涉及到的服務都得加！(我這里是在order-service、product-service加的依賴)
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency>
注意
之前加過Sleuth依賴，現在加zipkin依賴，2.x的zipkin已經包含sleuth了，這里可以把之前的sleuth依賴去掉
修改組態檔
默認指向的zipkin地址為本機地址：http://localhost:9411/
默認收集百分比為：10%
application.properties
# 指定zipkin地址
spring.zipkin.base-url=http://localhost:9411/
# 配置采樣百分比，開發環境可以設定：1，也就是100%，生產環境可以設定小一點
spring.sleuth.sampler.probability=1
啟動并分析資料
通過這個分析，我們可以知道，微服務中那個服務耗時多，可以在這個服務上做性能優化，可以考慮加：快取、異步、演算法等等~
原始碼下載
好了，今天先到這，只可意會不可言傳，自己體會他的好處~
鏈接: https://pan.baidu.com/s/1c4ZWufjmDgzgAAiOOzRg9A 密碼: or12
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/215639.html
標籤：其他