導讀

　　微服務架構中，是否遇到過這種情況，服務間呼叫鏈過長，導致效能遲遲上不去，不知道哪裡出問題了，巴拉巴拉....，迴歸正題，今天我們使用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