最簡單易懂的SpringCloudSleuth教程(spring cloud體系的鏈路追蹤系統)

 

最簡單易懂的SpringCloudSleuth教程 - 簡書
https://www.jianshu.com/p/71f0b054c558

 

 

 

最簡單易懂的SpringCloudSleuth教程(spring cloud體系的鏈路追蹤系統)

 

 

普元推出DevOps系列課程，5分鐘秒懂一個知識點，戳“閱讀原文”充電5分鐘，掌握黑科技。

 

轉載本文需註明出處：微信公衆號EAWorld，違者必究。

 

隨着分佈式服務架構的流行，特別是微服務等設計理念在系統中的應用，系統規模也會變得越來越大，各微服務間的調用關係也變得越來越複雜。通常一個由客戶端發起的請求在後端系統中會經過多個不同的微服務調用來協同產生最後的請求結果。

 

在複雜的微服務架構系統中，幾乎每一個前端請求都會形成一個複雜的分佈式服務調用鏈路。那麼就帶來一系列問題，在業務規模不斷增大、服務不斷增多以及頻繁變更的情況下，如何快速發現問題？如何判斷故障影響範圍？如何梳理服務依賴以及依賴的合理性？如何分析鏈路性能問題以及實時容量規劃？面對上面這些問題，Spring Cloud Sleuth提供了分佈式服務跟蹤解決方案。 

 

 

目錄：

一、爲什麼需要以及什麼是分佈式服務跟蹤系統

二、分佈式服務跟蹤：SpringCloudSleuth

三、分佈式服務跟蹤系統其他解決方案

 

一、爲什麼需要以及什麼是

分佈式服務跟蹤系統

 

• 爲什麼需要分佈式服務跟蹤系統

 

隨着分佈式服務架構的流行，特別是微服務等設計理念在系統中的應用，業務的調用鏈越來越複雜。

 

 

可以看到，隨着業務的發展，系統規模也會變得越來越大，各微服務間的調用關係也變得越來越複雜。通常一個由客戶端發起的請求在後端系統中會經過多個不同的微服務調用來協同產生最後的請求結果，在複雜的微服務架構系統中，幾乎每一個前端請求都會形成一個複雜的分佈式服務調用鏈路，在每條鏈路中任何一個依賴服務出現延遲過高或者錯誤都有可能引起請求最後的失敗。同時，缺乏一個自上而下全局的調用id，如何有效的進行相關的數據分析工作？對於大型網站系統，如淘寶、京東等電商網站，這些問題尤其突出。

 

• 什麼是分佈式服務跟蹤系統

 

分佈式服務跟蹤是整個分佈式系統中跟蹤一個用戶請求的過程（包括數據採集、數據傳輸、數據存儲、數據分析、數據可視化），捕獲此類跟蹤讓我們構建用戶交互背後的整個調用鏈的視圖，這是調試和監控微服務的關鍵工具。Spring Cloud Sleuth是Spring Cloud爲分佈式服務跟蹤提供的解決方案，有了它，我們可以：

 

 

• 提供鏈路追蹤，故障快速定位：可以通過調用鏈結合業務日誌快速定位錯誤信息。

• 可視化各個階段耗時，進行性能分析

• 各個調用環節的可用性、梳理服務依賴關係以及優化

• 數據分析，優化鏈路：可以得到用戶的行爲路徑，彙總分析應用在很多業務場景。

 

下面我們來看一個典型的分佈式系統請求調用過程，如下圖所示：

 

 

• 分佈式服務跟蹤系統的設計

 

 

• 分佈式服務跟蹤系統設計目標

低入侵性，應用透明：即作爲也業務組件，應當儘可能少入侵或者無入侵其他業務系統，對於使用方透明，減少開發人員的負擔。

低損耗：服務調用埋點本身會帶來性能損耗，這就需要調用跟蹤的低損耗，實際中還會通過配置採樣率的方式，選擇一部分請求去分析請求路徑。

大範圍部署，擴展性：作爲分佈式系統的組件之一，一個優秀的調用跟蹤系統必須支持分佈式部署，具備良好的可擴展性。

 

• 埋點與生成日誌

埋點即系統在當前節點的上下文信息，可以分爲客戶端埋點、服務端埋點，以及客戶端和服務端雙向型埋點。埋點日誌通常要包含以下內容traceId、spanId、調用的開始時間，協議類型、調用方ip和端口，請求的服務名、調用耗時，調用結果，異常信息等，同時預留可擴展字段，爲下一步擴展做準備；

 

• 收集和存儲日誌（主要支持分佈式日誌採集的方案，同時增加MQ作爲緩衝）

• 分析和統計調用鏈路數據，以及時效性

• 展現以及決策支持

 

二、分佈式服務跟蹤：

SpringCloudSleuth

 

• 快速入門

 

在引入Sleuth之前，我們需要做一些準備工作，具體如下所示：

 

 

• 服務註冊中心（eureka-server）

• 微服務應用分別爲trace1和trace2（它們都有一個REST接口，其中trace1通過RestTemplate調用trace2的REST接口）

微服務應用trace1和trace2項目基本一樣（除配置端口、應用名稱和REST的Path），以trace1爲示例：

 

• pom.xml文件增加依賴（如下所示）

 

 

• 主要代碼：

 

 

• 配置文件

 

 

• 運行結果，日誌沒有沒有跟蹤信息

 

我們在瀏覽器或者postman通過http：//localhost:8080/trace1,可以返回trace2相應接口的內容，同時我們看到控制檯並沒有跟蹤信息打印，微服務應用trace1和trace2的日誌信息具體如下圖所示：

 

 

 

• 添加跟蹤依賴 ，日誌信息存在跟蹤信息

 

如何爲上面的trace1和trace2添加服務跟蹤功能呢？SpringCloudSleuth對於此進行封裝，使得我們爲應用增加服務跟蹤能力的操作非常簡單，滿足前面所說設計目標（低入侵，應用透明），只需在trace1和trace2的pom.xml依賴管理中增加Spring-cloud-starter-sleuth依賴即可，具體如下所示：

 

<dependency>

         <groupId>org.springframework.cloud</groupId>

         <artifactId>spring-cloud-starter-sleuth</artifactId>

     </dependency>

 

添加sleuth依賴後，分別重啓trace1和trace2，再次通過瀏覽器或者postman調用http：//localhost:8080/trace1,可以返回trace2相應接口的內容，同時我們看到控制檯日誌已經存在跟蹤信息，微服務應用trace1和trace2的日誌信息具體如下圖所示：

 

 

從上面的控制檯輸出內容中，我們看到多出了一些形如[trace1,454445a6a7d9ea44,912a7c66c17214e0,false]的日誌信息，而這些元素正是實現分佈式服務跟蹤的重要組成部分，它們的含義分別如下所示：

 

 

第一個值：trace1，它表示應用的名稱，也就是配置文件spring.application.name的值。

第二個值：454445a6a7d9ea44，它是SpringCloudSleuth生成的一個ID，稱爲Trace ID，它用來標識一條請求鏈路，一條請求鏈路中包含一個Trace ID，多個Span ID。

第三個值：912a7c66c17214e0，它是SpringCloudSleuth生成的另外一個ID，稱爲Span ID，它表示一個基本的工作單元，比如發送一個http請求。

第四個值：false，表示是否要將該信息輸出到Zipkin等服務中來收集和展示。

 

上面四個值中的Trace ID 和Span ID是SpringCloudSleuth實現分佈式服務跟蹤的核心。在一次服務請求鏈路的調用過程中，會保持並傳遞同一個Trace ID，從而將整個分佈於不同微服務進程中的請求跟蹤信息串聯起來。例如，在一次前端請求鏈路中，上面trace1和trace2的Trace ID是相同的。

 

• 跟蹤原理

 

 

分佈式服務跟蹤系統主要包括下面三個關鍵點：

 

（1）Trace：它是由一組有相同Trace ID的Span串聯形成一個樹狀結構。爲了實現請求跟蹤，當請求請求到分佈式系統的入口端點時，只需要服務跟蹤框架爲該請求創建一個唯一的跟蹤標識（即前文提到的Trace ID），同時在分佈式系統內部流轉的時候，框架始終保持傳遞該唯一標識，直到返回請求爲止，我們通過它將所有請求過程中的日誌關聯起來；

 

（2）Span：它代表了一個基礎的工作單元，例如服務調用。爲了統計各處理單元的時間延遲，當前請求到達各個服務組件時，也通過一個唯一標識（即前文提到的Span ID）來標記它的開始、具體過程以及結束。通過span的開始和結束的時間戳，就能統計該span的時間延遲，除此之外，我們還可以獲取如事件名稱、請求信息等元數據。

 

 

（3）Annotation：它用於記錄一段時間內的事件。內部使用的最重要的註釋是：

 

• cs （Client Send）：客戶端發出請求，爲開始跨度

• sr （Server Received）：服務器已收到請求並開始處理。timestampsr - timestampcs =網絡延遲。

• ss （Server Send）：服務器處理完畢準備發送到客戶端。timestampss - timestampsr =服務器上的請求處理時間。

• cr （Client Received）：客戶端接收到服務器響應，爲跨度結束。客戶端已成功接收到服務器的響應。timestampcr - timestampcs =請求的總時間。

以下是在使用Sleuth的兩個微服務之間的調用中請求的行爲方式，除了生成唯一標識符並將其添加到應用程序日誌之外，還需要在作爲請求的一部分的微服務器之間正確傳播它們。

 

 

• 抽樣收集

 

我們在對接分析系統時就會碰到一個問題：分析系統在收集跟蹤信息的時候，需要收集多少跟蹤信息才合適呢？生產環境與開發環境跟蹤信息收集比例應該不一致，我們是否可以調整呢？同時，不同業務系統收集比例可能也不一樣。

 

理論上來說，我們收集的跟蹤信息越多就可以越好反映出系統的實際運行情況，並給出更精確的預警和分析。但在高併發的分佈式系統運行時，大量的請求調用會產生海量的跟蹤日誌信息，如果收集過多的跟蹤信息將會對整個分佈式系統的性能造成一定的影響，同時保存大量的日誌信息也需要不少的存儲開銷。所以，在Sleuth中採用了抽象收集的方式來跟蹤信息打上標記，也就是我們前面第四個布爾值，它代表了該信息是否要被後續的跟蹤信息收集器獲取和存儲。

 

默認情況下，Sleuth會使用PercentageBasedSampler實現的抽樣策略，以請求百分比的方式配置和收集跟蹤信息，默認值0.1（代表收集10%的請求跟蹤信息），可以通過配置spring.sleuth.sampler來修改收集的百分比。

 

• 與ELK整合

 

前面隨着已經有了跟蹤信息，但是由於日誌文件都分佈在各個服務實例的文件系統上，如果鏈路上服務比較多，查看日誌文件定位問題是一件非常麻煩的事情，所以我們需要一些工具來幫忙集中收集、存儲和搜素這些跟蹤信息。引入基於日誌的分析系統是一個不錯的選擇，比如ELK平臺，SpringCloudSleuth在與ELK平臺整合使用時，實際上只需要與負責日誌收集的Logstash完成數據對接即可，所以我們需要爲logstash準備Json格式的日誌輸出（SpringBoot應用默認使用logback來記錄日誌，而logstash自身也有對logback日誌工具支持）。與ELK整合架構圖如下所示：

 

 

• 與Zipkin整合

 

雖然通過ELK平臺提供的收集、存儲、搜索等強大功能，但是缺少對請求鏈路中各階段時間延遲的關注，而很多時候我們追溯請求鏈路的一個原因是爲了找出整個鏈路中出現延遲過高的瓶頸源，或者找出問題服務實例等監控與時間消耗相關的需求，ELK就顯得乏力，反而引入Zipkin就能夠輕鬆解決。

 

Zipkin是Twitter的一個開源項目，它基於Google Dapper實現。我們可以使用它來收集各個服務器上請求鏈路的跟蹤數據，並通過它提供的Rest API接口來輔助查詢跟蹤數據以分佈式系統的監控程序，通過UI組件幫助我們及時發現系統中出現的延遲升高問題以及系統性能瓶頸根源。下面展示Zipkin的基礎架構，它主要由4個核心組件構成：

 

Collector（收集器組件）：主要負責收集外部系統跟蹤信息，轉化爲Zipkin內部的Span格式。

Storage（存儲組件）：主要負責收到的跟蹤信息的存儲，默認爲內存，同時支持存儲到Mysql、Cassandra以及Elasticsearch。

Restful API（API組件）：提供接口，方便外部系統進行集成。

Web UI（展示組件）：基於API開發的自帶展示界面，方便進行跟蹤信息的查看以及查詢，同時進行相關的分析。

 

與zipkin整合——HTTP收集

 

sleuth收集跟蹤信息通過http請求發送給zipkin server，zipkinserver進行跟蹤信息的存儲以及提供Rest API即可，Zipkin UI調用其API接口進行數據展示。其大體路流程如下圖所示：

 

 

代碼如何實現呢？主要有兩個部分：搭建Zipkin Server、爲應用引入zipkin依賴和配置，具體如下所示：

 

（1）搭建Zipkin Server

 

添加Pom依賴

 

 

主要代碼

 

 

配置文件

 

 

（2）爲應用引入zipkin依賴和配置

 

添加Pom依賴

 

 

爲應用增加配置文件

 

 

啓動Zipkin Server以及分別重啓trace1和trace2，再次通過瀏覽器或者postman調用http：//localhost:8080/trace1,可以返回trace2相應接口的內容，同時我們看到控制檯日誌已經存在跟蹤信息，然後通過瀏覽器訪問http：//localhost:9411/,我們可以看到Zipkin對於跟蹤信息分析與展示，可以看到請求鏈路，以及每個span的具體耗時，就能分析進行鏈路優化、依賴分析等操作，其界面具體如下所示：

 

 

與zipkin整合——消息中間件收集

 

Spring Cloud Sleuth在整合Zipkin時，不僅實現了以Http的方式收集，還實現了通過消息中間件來對跟蹤信息進行異步收集。通過結合Spring Cloud Stream，我們可以非常輕鬆地讓應用客戶端將跟蹤信息輸出到消息中間件，同時Zipkin服務端從消息中間件上異步獲取這些跟蹤信息，具體如下所示：

 

 

代碼如何實現呢？主要有兩個部分：搭建Zipkin Server、爲應用引入zipkin依賴和配置，具體如下所示：

 

（1）搭建Zipkin Server

 

添加Pom依賴

 

主要代碼（使用註解@EnableZipkinStreamServer）

 

配置文件

 

 

（2）爲應用引入zipkin依賴和配置

 

添加Pom依賴

 

 

爲應用增加配置文件

 

 

與Zipkin整合——數據存儲

 

默認情況下，Zipkin Server會將跟蹤信息存儲在內存中，但是這樣就會出現我們重啓Zipkin Server時之前收集的跟蹤信息丟失的問題。爲了解決此問題，Zipkin提供了多種存儲方式，比如Mysql、Cassandra以及Elasticsearch，以Mysql爲例，我們能夠很輕鬆地爲Zipkin Server增加Mysql存儲功能。主要有三個步驟即可：第一步，在Mysql中創建數據庫並且運行其數據腳本；第二步，爲pom添加數據庫依賴；第三步，修改配置更換存儲方式。更多內容請我另一篇博客《微服務之分佈式跟蹤系統（springboot+zipkin）》。

（博客地址：http://blog.csdn.net/qq_21387171/article/details/53787019）

 

與Zipkin整合——API接口

 

Zipkin不僅提供了Web UI方便用戶進行跟蹤信息查看與查詢，同時還提供了Rest API，方便第三方系統進行集成進行跟蹤信息的展示和監控，其提供的API列表如下所示：

 

 

 

三、分佈式服務跟蹤系統其他解決方案

 

OpenTracing通過提供平臺無關、廠商無關的API，使得開發人員能夠方便的添加（或更換）追蹤系統的實現。 OpenTracing提供了用於運營支撐系統的和針對特定平臺的輔助程序庫。下面爲其相應的成員以及提供的產品：

 

 

分佈式服務跟蹤系統其他解決方案：Jaeger

 

Jaeger（https://github.com/jaegertracing/jaeger）受到Dapper和Zipkin的啓發，從開始就建立了OpenTracing支持，是由Uber Technologies作爲開源發佈的分佈式跟蹤系統。它可用於監控基於微服務的體系結構：分佈式上下文傳播、分佈式事務監控、根本原因分析、服務依賴性分析以及性能/延遲優化。其架構圖如下所示：

 

 

分佈式服務跟蹤系統其他解決方案： Sky Walking

 

Skywalking （https://github.com/wu-sheng/sky-walking）全鏈路監控開源項目，也是唯一的國內團隊開源的APM監控項目。其架構圖如下所示：

 

 

最後，附上文章所講內容的源碼下載地址（源碼地址：https://github.com/dreamerkr/SpringCloudSleuthExample.git ），需要可以進行下載與交流。

 

關於作者：

王召

現任普元信息資深開發工程師，爲普元新一代數字化企業雲平臺開發團隊一員，負責新一代SPM（軟件產品管理）與MKT（軟件市場）領域系統的開發。曾在百度西北營銷自主研發中心、格林談談科技等互聯網公司從事開發經理工作，曾主導開發過多款電商和社交項目，並獲得風險基金的投資。平時喜歡旅遊，騎行，爬山等活動。

 

 

 

關於EAWorld

微服務，DevOps，元數據，企業架構原創技術分享，EAii（Enterprise Architecture Innovation Institute）企業架構創新研究院旗下官方微信公衆號。

 

微信號：eaworld，長按二維碼關注

 

普元推出DevOps系列課程，5分鐘秒懂一個知識點，戳“閱讀原文”充電5分鐘，掌握黑科技↓↓↓

 

閱讀原文：http://mp.weixin.qq.com/s?timestamp=1506676654&src=3&ver=1&signature=NtQH4jkkXQHZr2DwB5ZVfRf0Wctr0V2zZLC6se43qy8yM1hL*fW6PBQnwwljQgijPuvoFpLt28foJktADY*ENeCdoqQBx*ldMlpKGWSri2rz3tFC9BL7RAL2DbFSq1kAt6vMZngB*yrFRAOB1XfPFVLxoH*yHPnjKQtKlym5hc0=&devicetype=Windows-QQBrowser&version=61030004&pass_ticket=qMx7ntinAtmqhVn+C23mCuwc9ZRyUp20kIusGgbFLi0=&uin=MTc1MDA1NjU1&ascene=1