封面圖是 凌晨 3點半起來更文的鎖屏桌面。

前言

從上週六 7 號到今天的 11 號，我都在醫院，小孩因肺炎已經住院了，我白天和晚上的時間需要照顧娃，只能在娃睡覺的時候肝文了。對了，醫院沒有寬頻和 WiFi，我用的手機開的熱點~

本篇主要內容

這篇主要是理論 + 實踐相結合。實踐部分涉及到如何把鏈路追蹤 Sleuth + Zipkin 加到我的 Spring Cloud 《佳必過》開源專案上。

本篇知識點：

• 鏈路追蹤基本原理
• 如何在專案中輕鬆加入鏈路追蹤中介軟體
• 如何使用鏈路追蹤排查問題。

一、為什麼要用鏈路追蹤？

1.1 因：拆分服務單元

微服務架構其實是一個分散式的架構，按照業務劃分成了多個服務單元。

由於服務單元的數量是很多的，有可能幾千個，而且業務也會更復雜，如果出現了錯誤和異常，很難去定位。

1.2 因：邏輯複雜

比如一個請求需要呼叫多個服務才能完成整個業務閉環，而內部服務的程式碼邏輯和業務邏輯比較複雜，假如某個服務出現了問題，是難以快速確定那個服務出問題的。

1.3 果：快速定位

而如果我們加上了分散式鏈路追蹤，去跟蹤一個請求有哪些服務參與其中，參與的順序是怎樣的，這樣我們就知道了每個請求的詳細經過，即使出了問題也能快速定位。

二、鏈路追蹤的核心

鏈路追蹤元件有 Twitter 的視覺化鏈路追蹤元件 Zipkin、Google 的 Dapper、阿里的 Eagleeye 等，而 Sleuth 是 Spring Cloud 的元件。Spring Cloud Sleuth 借鑑了 Dapper 的術語。

本文主要講解 Sleuth + Zipkin 結合使用來更好地實現鏈路追蹤。

為什麼能夠進行整條鏈路的追蹤？其實就是一個 Trace ID 將 一連串的 Span 資訊連起來了。根據 Span 記錄的資訊再進行整合就可以獲取整條鏈路的資訊。下面

2.1 Span（跨度）

• 大白話：遠端呼叫和 Span 一對一。

• 基本的工作單元，每次傳送一個遠端呼叫服務就會產生一個 Span。

• Span 是一個 64 位的唯一 ID。

• 通過計算 Span 的開始和結束時間，就可以統計每個服務呼叫所花費的時間。

2.2 Trace（跟蹤）

• 大白話：一個 Trace 對應多個 Span，一對多

  。

• 它由一系列 Span 組成，樹狀結構。

• 64 位唯一 ID。

• 每次客戶端訪問微服務系統的 API 介面，可能中間會呼叫多個微服務，每次呼叫都會產生一個新的 Span，而多個 Span 組成了 Trace

2.3 Annotation（註解）

鏈路追蹤系統定義了一些核心註解，用來定義一個請求的開始和結束，注意是微服務之間的請求，而不是瀏覽器或手機等裝置。註解包括：

• cs - Client Sent：客戶端傳送一個請求，描述了這個請求呼叫的 Span 的開始時間。注意：這裡的客戶端指的是微服務的呼叫者，不是我們理解的瀏覽器或手機等客戶端。
• sr - Server Received：服務端獲得請求並準備開始處理它，如果將其 sr 減去 cs 時間戳，即可得到網路傳輸時間。
• ss - Server Sent：服務端傳送響應，會記錄請求處理完成的時間，ss 時間戳減去 sr 時間戳，即可得到伺服器請求的時間。
• cr - Client Received：客戶端接收響應，Span 的結束時間，如果 cr 的時間戳減去 cs 時間戳，即可得到一次微服務呼叫所消耗的時間，也就是一個 Span 的消耗的總時間。

2.4 鏈路追蹤原理

假定三個微服務呼叫的鏈路如下圖所示：Service 1 呼叫 Service 2，Service 2 呼叫 Service 3 和 Service 4。

那麼鏈路追蹤會在每個服務呼叫的時候加上 Trace ID 和 Span ID。如下圖所示：

大白話解釋：

• 大家注意上面的顏色，相同顏色的代表是同一個 Span ID，說明是鏈路追蹤中的一個節點。

• 第一步：客戶端呼叫 Service 1，生成一個 Request，Trace ID 和 Span ID 為空，那個時候請求還沒有到 Service 1。

• 第二步：請求到達 Service 1，記錄了 Trace ID = X，Span ID 等於 A。

• 第三步：Service 1 傳送請求給 Service 2，Span ID 等於 B，被稱作 Client Sent，即客戶端傳送一個請求。

• 第四步：請求到達 Service 2，Span ID 等於 B，Trace ID 不會改變，被稱作 Server Received，即服務端獲得請求並準備開始處理它。

• 第五步：Service 2 開始處理這個請求，處理完之後，Trace ID 不變，Span ID = C。

• 第六步：Service 2 開始傳送這個請求給 Service 3，Trace ID 不變，Span ID = D，被稱作 Client Sent，即客戶端傳送一個請求。

• 第七步：Service 3 接收到這個請求，Span ID = D，被稱作 Server Received。

• 第八步：Service 3 開始處理這個請求，處理完之後，Span ID = E。

• 第九步：Service 3 開始傳送響應給 Service 2，Span ID = D，被稱作 Server Sent，即服務端傳送響應。

• 第十步：Service 3 收到 Service 2 的響應，Span ID = D，被稱作 Client Received，即客戶端接收響應。

• 第十一步：Service 2 開始返回 響應給 Service 1，Span ID = B，和第三步的 Span ID 相同，被稱作 Client Received，即客戶端接收響應。

• 第十二步：Service 1 處理完響應，Span ID = A，和第二步的 Span ID 相同。

• 第十三步：Service 1 開始向客戶端返回響應，Span ID = A、

• Service 3 向 Service 4 傳送請求和 Service 3 類似，對應的 Span ID 是 F 和 G。可以參照上面前面的第六步到第十步。

把以上的相同顏色的步驟簡化為下面的鏈路追蹤圖：

• 第一個節點：Span ID = A，Parent ID = null，Service 1 接收到請求。
• 第二個節點：Span ID = B，Parent ID= A，Service 1 傳送請求到 Service 2 返回響應給 Service 1 的過程。
• 第三個節點：Span ID = C，Parent ID= B，Service 2 的 中間處理過程。
• 第四個節點：Span ID = D，Parent ID= C，Service 2 傳送請求到 Service 3 返回響應給 Service 2 的過程。
• 第五個節點：Span ID = E，Parent ID= D，Service 3 的中間處理過程。
• 第六個節點：Span ID = F，Parent ID= C，Service 3 傳送請求到 Service 4 返回響應給 Service 3 的過程。
• 第七個節點：Span ID = G，Parent ID= F，Service 4 的中間處理過程。

通過 Parent ID 即可找到父節點，整個鏈路就可以進行跟蹤追溯了。

三、Spring Cloud 整合 Sleuth

大家可以參照我的 GitHub 開源專案 PassJava（佳必過）。

3.1 引入 Spring Cloud 依賴

在 passjava-common 中引入 Spring Cloud 依賴

因為我們使用的鏈路追蹤元件 Sleuth 是 Spring Cloud 的元件，所以我們需要引入 Spring Cloud 依賴。

<dependencyManagement>
    <dependencies>
        <!--  Spring Cloud 依賴  -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>Hoxton.SR3</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

3.2 引入Sleuth依賴

引入鏈路追蹤元件 Sleuth 非常簡單，在 pom.xml 檔案中引入 Sleuth 依賴即可。

在 passjava-common 中引入 Sleuth 依賴：

<!-- 鏈路追蹤元件 -->
<dependency>
	<groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

3.3 通過日誌觀察鏈路追蹤

我們先不整合 zipkin 鏈路追蹤視覺化元件，而是通過日誌的方式來檢視鏈路追蹤資訊。

檔案路徑：\PassJava-Platform\passjava-question\src\main\resources\application.properties
新增配置：
logging.level.org.springframework.cloud.openfeign=debug
logging.level.org.springframework.cloud.sleuth=debug

3.4 啟動微服務

啟動以下微服務：

• passjava-gateway 服務（閘道器）

• passjava-question 服務（題目中心微服務）

• renren 服務（Admin 後臺管理服務）

  啟動成功後如下圖所示：

3.5 測試跟蹤請求

開啟 Admin 後臺，訪問題目中心->題目配置頁面，可以看到傳送了下面的請求：

http://localhost:8060/api/question/v1/admin/question/list?t=1605170539929&page=1&limit=10&key=

開啟控制檯，可以看到打印出了追蹤日誌。

說明：

• 當沒有配置 Sleuth 鏈路追蹤的時候，INFO 資訊裡面是 [passjava-question,,,]，後面跟著三個空字串。
• 當配置了 Sleuth 鏈路追蹤的時候，追蹤到的資訊是 [passjava-question,504a5360ca906016,e55ff064b3941956,false] ，第一個是 Trace ID，第二個是 Span ID。

四、Zipkin 鏈路追蹤原理

上面我們通過簡單的引入 Sleuth 元件，就可以獲取到呼叫鏈路，但只能通過控制檯的輸出資訊來看，不太方便。

Zipkin 油然而生，一個圖形化的工具。Zipkin 是 Twitter 開源的分散式跟蹤系統，主要用來用來收集系統的時序資料，進而可以跟蹤系統的呼叫問題。

而且引入了 Zipkin 元件後，就不需要引入 Sleuth 元件了，因為 Zipkin 元件已經幫我們引入了。

Zipkin 的官文：https://zipkin.io

4.1 Zipkin 基礎架構

Zipkin 包含四大元件：

• Collection（收集器元件），主要負責收集外部系統跟蹤資訊。
• Storage（儲存元件），主要負責將收集到的跟蹤資訊進行儲存，預設存放在記憶體中，支援儲存到 MySQL 和 ElasticSearch。
• API（查詢元件），提供介面查詢跟蹤資訊，給 UI 元件用的。
• UI （視覺化 Web UI 元件），可以基於服務、時間、註解來視覺化檢視跟蹤資訊。注意：Web UI 不需要身份驗證。

4.2 Zipkin 跟蹤流程

流程解釋：

• 第一步：使用者程式碼發起 HTTP Get 請求，請求路徑：/foo。
• 第二步：請求到到跟蹤工具後，請求被攔截，會被記錄兩項資訊：標籤和時間戳。以及HTTP Headers 裡面會增加跟蹤頭資訊。
• 第三步：將封裝好的請求傳給 HTTP 客戶端，請求中包含 X-B3-TraceID 和 X-B3-SpanId 請求頭資訊。
• 第四步：由HTTP 客戶端傳送請求。
• 第五步：Http 客戶端返回響應 200 OK 後，跟蹤工具記錄耗時時間。
• 第六步：跟蹤工具傳送 200 OK 給使用者端。
• 第七步：非同步報告 Span 資訊給 Zipkin 收集器。

五、整合 Zipkin 視覺化元件

5.1 啟動虛擬機器並連線

vagrant up

用 Xshell 工具連線 虛擬機器。

5.2 docker 安裝 zipkin 服務

• 使用以下命令開始拉取 zipkin 映象並啟動 zipkin 容器。

docker run -d -p 9411:9411 openzipkin/zipkin

• 命令執行完後，會執行下載操作和啟動操作。

• 使用 docker ps 命令可以看到 zipkin 容器已經啟動成功了。如下圖所示：

• 在瀏覽器視窗開啟 zipkin UI

訪問服務地址：http://192.168.56.10:9411/zipkin。

5.3 引入 Zipkin 依賴

在公共模組引入 zipkin 依賴

<!-- 鏈路追蹤元件 Zipkin -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

因為 zipkin 包裡面已經引入了 sleuth 元件，所以可以把之前引入的 sleuth 元件刪掉。

5.4 新增 Zipkin 配置

在需要追蹤的微服務模組下新增 zipkin 配置。

# zipkin 的伺服器地址
spring.zipkin.base-url=http://192.168.56.10:9411/
# 關閉服務發現，否則 Spring Cloud 會把 zipkin 的 URL 當作服務名稱。
spring.zipkin.discovery-client-enabled=false
# 設定使用 http 的方式傳輸資料，也可以用 RabbitMQ 或 Kafka。
spring.zipkin.sender.type=web
# 設定取樣率為 100 %，預設為 0.1（10%）
spring.sleuth.sampler.probability=1

5.5 測試 Zipkin 是否工作

這裡我在 passjava-member 微服務中寫了一個 API：

passjava-member 服務的 API：getMemberStudyTimeListTest，訪問路徑為/studytime/list/test/{id}。

passjava-member 服務遠端呼叫 passjava-study 服務的 API：getMemberStudyTimeListTest。

我用 postman 工具測試 member 服務的 API：

開啟 Zipkin 工具，搜尋 passjava-member 的鏈路追蹤日誌，可以看到有一條記錄，相關說明如下圖所示：

從圖中可以看到 passjava-member 微服務呼叫了 passjava-study 微服務，如圖中左半部分所示。

而且 passjava-study 微服務詳細的呼叫時間都記錄得非常清楚，如圖中右半部分所示。

時間計算：

• 請求傳輸時間：Server Start - Client Start = 2.577s-2.339s = 0.238s
• 服務端處理時間：Server Finish - Server Start = 2.863s - 2.577s = 0.286s
• 請求總耗時：Client Finish - Client Start = 2.861s - 2.339s = 0.522s
• Passjava-member 服務總耗時：3.156 s
• Passjava-study 服務總耗時：0.521s
• 由此可以看出 passjava-member 服務花費了很長時間，效能很差。

還可以用圖示的方式檢視：

六、Zipkin 資料持久化

6.1 Zipkin 支援的資料庫

Zipkin 儲存資料預設是放在記憶體中的，如果 Zipkin 重啟，那麼監控資料也會丟失。如果是生成環境，資料丟失會帶來很大問題，所以需要將 Zipkin 的監控資料持久化。而 Zipkin 支援將資料儲存到以下資料庫：

• 記憶體（預設，不建議使用）
• MySQL（資料量大的話， 查詢較為緩慢，不建議使用）
• Elasticsearch（建議使用）
• Cassandra（國內使用 Cassandra 的公司較少，相關文件也不多）

6.2 使用 Elasticsearch 作為儲存介質

• 通過 docker 的方式配置 elasticsearch 作為 zipkin 資料的儲存介質。

docker run --env STORAGE_TYPE=elasticsearch --env ES_HOSTS=192.168.56.10:9200 openzipkin/zipkin-dependencies

• ES 作為儲存介質的配置引數：

七、總結

本篇講解了鏈路追蹤的核心原理，以及 Sleuth + Zipkin 的元件的原理，以及將這兩款元件加到了我的開源專案《佳必過》裡面了。

開源專案地址：https://github.com/Jackson0714/PassJava-Platform

寫在最後

這周真的身心俱疲，娃也是受罪，出院後，娃吃飯也不像以前那麼積極了，看到醫生那種衣服就怕，連看到照片印表機都怕了。生怕是要給他打針、吃藥、做霧化的。還未結婚生娃的抓緊時間學習吧，加油少年~

我是悟空，努力變強，變身超級賽亞人！手寫了一套 Spring Cloud 進階教程和 PMP 刷題小程式。