共計 1705 個字符，預計需要花費 5 分鐘才能閱讀完成。

這篇文章主要介紹了 Spring Cloud 中微服務跟蹤的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓丸趣 TV 小編帶著大家一起了解一下。

微服務跟蹤概述

  先對微服務跟蹤的相關概念，做一個基本的講解。

實際問題與 Sleuth

  前面章節中，我們使用 Spring Cloud 來搭建服務集群，不論是 Eureka 服務器、服務實例，還是配置服務器、網關等節點，都可以橫向擴展。一旦集群中的服務數量增多，并且它們之間存在復雜的依賴關系，那么管理它們將會變成一件很棘手的事情。

  當外部用戶向集群發起請求，這些請求將會調用多個服務，每個服務又會依賴其他的服務，此時，如果出現異常、超時等情況，排查問題將變得非常困難。我們需要很清楚知道，服務出現了什么問題，這些問題出在哪個環節。

  為了能解決這些問題，Spring Cloud 提供了 Sleuth 框架作為解決方案，Sleuth 可以與 Zipkin、Apache HTrace 和 ELK 等數據分析、服務跟蹤系統進行整合，為服務跟蹤、解決問題提供了便利。

服務跟蹤系統

  目前有許多的分布式跟蹤系統，例如 Zipkin、HTrace 等，這些系統可以幫助我們收集一些，由服務實時產生的數據（主要是日志），通過這些數據可以分析出分布式系統的健康狀態、服務調用過程、調用耗時等指標，為優化系統、解決問題提供了依據。

  讀者需要區別兩個基本的概念：服務跟蹤和數據分析，數據分析系統（例如 ELK 等）收集了服務集群所產生的數據后，也可以實現服務監控、服務跟蹤等功能，但明顯數據分析系統的概念更為廣泛、抽象。本書將會介紹服務跟蹤系統 Zipkin，同樣也會介紹著名的數據分析平臺 ELK。

Sleuth 基本概念

 Sleuth 借鑒了 Google Dapper 的設計，先了解以下兩個概念：

Trace：表示整個跟蹤的過程，從用戶發起請求，到最終的響應。一次跟蹤包含多個跨度，這些跨度以樹狀結構進行保存。

Span：跨度，表示一次調用的過程，一次跟蹤包含多次的調用過程。假設用戶向 A 服務發送請求，A 服務又要調用 B 服務，那么此時將會產生兩個跨度：用戶調用 A 服務、A 服務調用 B 服務。

  圖 10- 1 簡單地描述了跨度的概念。

圖 10-1 跨度

  如圖 10-1，用戶或外部程序調用 A 服務，此次調用看作是跨度 A，A 服務還要調用 B 服務，在跨度 A 的基礎上會產生跨度 B，跨度 B 是跨度 A 的一部分，在 Sleuth 的設計上，跨度 A 是 B 的父跨度。因此在整個跟蹤過程中，這些跨度是樹狀結構的。

  除了跟蹤和跨度外，還要了解一下 Annotation（事件標識），它主要用于記錄事件的存在，主要包括以下幾個事件標識：

cs：Client Sent，表示客戶端發送了請求，這個標識意味著跨度的開始。例如前面的 A 服務向 B 服務發送請求，A 服務就是客戶端。

sr：Server Received，表示服務端接收到請求，并開始進行處理。

ss：Server Sent，表示服務器端完成請求的處理，并對客戶端做出響應。

cr：Client Received，表示客戶端接收到響應，意味著整個跨度的結束。

項目準備

  在使用 Sleuth 前，先準備本章的測試項目，本章主要以一個微服務集群為基礎，該集群包括以下項目：

test-eureka-server：Eureka 服務器，端口為 8761。

test-book-service：圖書微服務，主要提供根據 id 查詢圖書的服務，端口為 8081。

test-pay-service：支付微服務，主要提供支付服務，端口為 8082。

test-sale-service：銷售微服務，會調用圖書服務和支付服務，端口為 8083。

  以上的項目，均可以在 codes\10 目錄找到對應的源碼，幾個項目的結構請見圖 10-2。

圖 10-2 測試項目結構

  以上幾個測試項目是一個簡單的 Spring Cloud 集群，銷售服務依賴了“圖書服務”和“支付服務”。

感謝你能夠認真閱讀完這篇文章，希望丸趣 TV 小編分享的“Spring Cloud 中微服務跟蹤的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持丸趣 TV，關注丸趣 TV 行業資訊頻道，更多相關知識等著你來學習!