7. Spring Cloud Sleuth+ZipKin 鏈路監控的配置詳細解析

Rainbow-Sea發表於2024-11-28
SpringCloud

7. Spring Cloud Sleuth+ZipKin 鏈路監控的配置詳細解析

@

目錄
  • 7. Spring Cloud Sleuth+ZipKin 鏈路監控的配置詳細解析
  • 前言:
  • 1. Spring Cloud Sleuth + ZipKin 的概述
    • 1.1 Sleuth / ZipKin 是什麼 ？
    • 1.2 Sleuth 和 Zipkin 的簡單關係圖：
    • 1.3 Sleuth 工作原理解析
  • 2. Sleuth + ZipKin 的安裝 + 執行
  • 3. Sleuth / ZipKin-搭建鏈路監控例項
  • 4. 總結:
  • 5. 最後：

前言:

  • 對應上一篇學習內容：🌟🌟🌟6. Spring Cloud Gateway閘道器超詳細內容配置解析說明-CSDN部落格
  • 對應下一篇學習內容：🌟🌟🌟

1. Spring Cloud Sleuth + ZipKin 的概述

Spring Cloud Sleuth 的官方文件地址：https://github.com/spring-cloud/spring-cloud-sleuth

在這裡插入圖片描述

1.1 Sleuth / ZipKin 是什麼 ？

  1. 在微服務框架中，一個由客戶端發起的請求在後端系統中會經過多個不同的服務節點呼叫 ，來協同產生最後的請求結果，每一個請求都會形成一條複雜的分散式服務呼叫鏈路。

在這裡插入圖片描述

在這裡插入圖片描述

  1. 鏈路中的任何一條出現高延時 或錯誤 都會引起整個請求最後的失敗，因此對整個服務的呼叫進行鏈路追蹤和分析 就非常的重要。

而 Spring Cloud Sleuth 就是來解決這個我們在整個服務的呼叫的過程的各個服務節點上的鏈路追蹤+鏈路分析的 。+ ZipKin 在這整個服務的呼叫過程的資料蒐集+儲存+視覺化 。

在微服務系統中，少則五六個服務，多則上百個服務，如果某個環節出現問題了，一次呼叫可能涉及到很多服務，如果服務之間的日誌沒有關聯，那麼排查起來非常困難，這個時候就需要鏈路追蹤 。

鏈路追蹤 可以視覺化 地追蹤請求從一個微服務到另一個微服務的呼叫情況，從而幫助問題的排查。另外一個方面就是鏈路追蹤還可以幫助最佳化效能，視覺化服務之間的依賴關係，並進行服務的監控 與報警 。

簡單的實現就是在日誌中定義一個統一的 TraceId ，串聯整體呼叫鏈路，每個服務之間還會定義一個 spanId ，標誌服務內的呼叫鏈路 。

Spring Cloud 中常用的微服務鏈路追蹤方案：

Spring Cloud Sleuth + ZipKin(組合使用簡單，整合度高，是 Spring Cloud 生態中常用的鏈路追蹤解決方案)

  • Spring Cloud Sleuth ： 是 Spring Cloud 提供的分散式鏈路追蹤庫，它會在每個請求中自動生成 Trace ID 和 Span ID ，並將這些 ID 傳遞到呼叫鏈中的所有服務中，確保請求的追蹤資訊在各個微服務之間的傳遞。
  • ZipKin ：是一種分散式追蹤系統，支援收集和展示 Spring Cloud Sleuth 生成的追蹤資料。她能夠將每個請求詳細路徑進行視覺化展示，便於開發者分析和排查問題。

1.2 Sleuth 和 Zipkin 的簡單關係圖：

在這裡插入圖片描述

在這裡插入圖片描述

重點：

  • Sleuth 做鏈路追蹤，ZipKin 做資料蒐集+儲存+視覺化 。
  • Sleuth 提供了一套完整的服務跟蹤的解決方案 ，併相容 ZipKin(資料收集) 。

1.3 Sleuth 工作原理解析

Span 和 Trace 在一個系統中使用 Zipkin 的過程-圖形化。如下圖所示：

在這裡插入圖片描述

講解說明：

  • 表示一請求鏈路，一條鏈路透過 Trace Id 唯一標識，Span 標識發起的請求資訊，各 span 透過 parent id 關聯起來。
  • Trace： 類似於樹結構的 Span 集合，表示一條呼叫鏈路，存在唯一標識 。
  • Span： 基本工作單元，表示呼叫鏈路來源，通俗的理解 span 就是一次請求資訊。

在這裡插入圖片描述

  • Trace ID： 表示整個呼叫鏈的唯一標識。當一個請求發起時，系統會生成一個 Trace ID，用於表示該請求在整個系統中的流轉路徑。
  • Trace： 是由一系列 Span 組成，呈樹狀結構。請求一個微服務系統的 API 介面，整個API介面需要呼叫多個微服務單元，呼叫每個微服務單元都會產生一個新的 Span，所有由這個請求產生的 Span 組成了整個 Trace
  • Span ID: 每個服務處理請求的一個單元稱為一個 Span ，每個 Span 都有一個唯一的 Span ID 。Span 記錄了每個微服務在呼叫鏈中的處理時間，日誌和後設資料。
  • Span: 是基本工作單元，傳送一個遠端排程任務就會產生一個 Span ，Span是用一個 64位ID，唯一標識的，Trace 是用另一個64位ID 唯一標識的，Span 還包含了其它資訊，例如：摘要，時間戳事件，Span的ID以及程序ID。
  • Span 關係： Span 之間可以有父子關係 ，一個 Trace 可以包含多個 Span ，用於描述微服務之間的呼叫關係。這些關係構成了呼叫鏈樹。

spans 的 parent/child 關係圖形化

在這裡插入圖片描述

講解說明：

  • 注意看老師標識的紅線 ，後一個 span節點的 parent Id 指向/記錄 的是 上一個 Span 。
  • span就是一次請求資訊，多個Span集合就構成一條呼叫鏈路，在span=C 這個節點存在分支。Sleuth/ZipKin-搭建鏈路監控例項。

2. Sleuth + ZipKin 的安裝 + 執行

安裝 Sleuth 的官網網址：https://repo1.maven.org/maven2/io/zipkin/java/zipkin-server/2.12.9/

在這裡插入圖片描述

下載得到 : zipkin-server-2.12.9-exec.jar

把 zipkin-server-2.12.9-exec.jar 放到指定的目錄 , 比如 G:\dev

在這裡插入圖片描述

在該(G:\dev)目錄下，進入 cmd , 執行指令執行: java -jar zipkin-server-2.12.9-exec.jar

java -jar zipkin-server-2.12.9-exec.jar

在這裡插入圖片描述

在這裡插入圖片描述

瀏覽器輸入:http://localhost:9411/zipkin/。注意：不要關閉命令視窗，不要關閉 剛剛執行的ziplin程式 。

在這裡插入圖片描述

3. Sleuth / ZipKin-搭建鏈路監控例項

需求說明/圖解

在瀏覽器輸入 : http://localhost/member/consumer/get/1 , 會返回對應的結果(如圖)

在這裡插入圖片描述

要求: 透過 Sleuth 和 Zipkin 可以對服務呼叫鏈路進行監控, 並在 Zipkin 進行顯示(如 圖)

在這裡插入圖片描述

  1. 修改我們前面 member-service-provider-10000 的 模組當中的，pom.xml , 增加引入 sleuth+zipkin。

在這裡插入圖片描述

     <!--包含了 sleuth+zipkin-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zipkin</artifactId>
        </dependency>
  1. 修改 member-service-provider-10000 的模組當中的 appliaction.xml , 指定 Zipkin的同時，配置 sleuth 資訊如下：

在這裡插入圖片描述

server:
  port: 10000
spring:
  application:
    name: member-service-provider # 配置應用的名稱
  # 配置 sleuth 和 zipkin
  zipkin:
    # 配置 zipkin 的 url 地址，是網路當中給的哪個  zipkin 地址
    base-url: http://localhost:9411/

  # 配置 sleuth 資訊
  sleuth:
    sampler:
      # 取樣率: 在 0~1之間，1表示全部採集
      probability: 1
  1. 服務消費方整合 Sleuth/Zipkin：修改 member-service-consumer-80 的模組當中的 pom.xml , 增加引入 sleuth+zipkin 即可。

在這裡插入圖片描述

     <!--包含了 sleuth+zipkin-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zipkin</artifactId>
        </dependency>
  1. 修改 member-service-consumer-80 的模組 appliaction.xml , 指定 Zipkin的同時，配置 sleuth 資訊如下：

在這裡插入圖片描述

server:
  port: 80 # 瀏覽器預設就是 80 埠

spring:
  application:
    name: member-service-consumer-80 # 該專案/模組名稱
    # 配置 zipkin + sleuth 資訊
  zipkin:
    # zipkin 網路當中的哪個 zipkin
    base-url: http://localhost:9411
  # 配置 sleuth 資訊
  sleuth:
    sampler:
      # 取樣率: 在0-1之間 ,1表示全部採集
      probability: 1

測試：

  1. 啟動 e-commerce-eureka-server-9001
  2. 啟動 member-service-provider-10000
  3. 啟動 member-service-consumer-80
  4. 瀏覽器: 瀏覽器輸入: http://localhost/member/consumer/get/1

瀏覽器輸入: http://localhost/member/consumer/get/1 , 多訪問幾次，方便看監控結果：

在這裡插入圖片描述

檢視監控&分析結果：

檢視 Zipkin : http://localhost:9411/zipkin/：

選擇某個服務，看結果：

在這裡插入圖片描述

在這裡插入圖片描述

檢視一次呼叫鏈路的深度，以及該鏈路包含請求 各個請求耗時，找到請求瓶頸，為 ,
最佳化提供依據(重要)：

在這裡插入圖片描述

在這裡插入圖片描述

在這裡插入圖片描述

檢視服務呼叫的依賴關係：

在這裡插入圖片描述

4. 總結:

  1. 簡單的實現就是在日誌中定義一個統一的 TraceId ，串聯整體呼叫鏈路，每個服務之間還會定義一個 spanId ，標誌服務內的呼叫鏈路 。
  2. Spring Cloud Sleuth + ZipKin(組合使用簡單，整合度高，是 Spring Cloud 生態中常用的鏈路追蹤解決方案)
    • Spring Cloud Sleuth ： 是 Spring Cloud 提供的分散式鏈路追蹤庫，它會在每個請求中自動生成 Trace ID 和 Span ID ，並將這些 ID 傳遞到呼叫鏈中的所有服務中，確保請求的追蹤資訊在各個微服務之間的傳遞。
    • ZipKin ：是一種分散式追蹤系統，支援收集和展示 Spring Cloud Sleuth 生成的追蹤資料。她能夠將每個請求詳細路徑進行視覺化展示，便於開發者分析和排查問題。

在這裡插入圖片描述

  1. 在這裡插入圖片描述

5. 最後：

“在這個最後的篇章中，我要表達我對每一位讀者的感激之情。你們的關注和回覆是我創作的動力源泉，我從你們身上吸取了無盡的靈感與勇氣。我會將你們的鼓勵留在心底，繼續在其他的領域奮鬥。感謝你們，我們總會在某個時刻再次相遇。”

在這裡插入圖片描述

相關文章