Spring Cloud中微服務跟蹤的示例分析

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

微服務跟蹤概述

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

實際問題與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集群，銷售服務依賴了“圖書服務”和“支付服務”。

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