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

轉(zhuǎn)載本文需注明出處：微信公眾號EAWorld掠拳，違者必究。

隨著分布式服務(wù)架構(gòu)的流行纸肉，特別是微服務(wù)等設(shè)計理念在系統(tǒng)中的應(yīng)用溺欧，系統(tǒng)規(guī)模也會變得越來越大，各微服務(wù)間的調(diào)用關(guān)系也變得越來越復(fù)雜柏肪。通常一個由客戶端發(fā)起的請求在后端系統(tǒng)中會經(jīng)過多個不同的微服務(wù)調(diào)用來協(xié)同產(chǎn)生最后的請求結(jié)果姐刁。

在復(fù)雜的微服務(wù)架構(gòu)系統(tǒng)中，幾乎每一個前端請求都會形成一個復(fù)雜的分布式服務(wù)調(diào)用鏈路烦味。那么就帶來一系列問題龙填，在業(yè)務(wù)規(guī)模不斷增大、服務(wù)不斷增多以及頻繁變更的情況下，如何快速發(fā)現(xiàn)問題岩遗？如何判斷故障影響范圍？如何梳理服務(wù)依賴以及依賴的合理性凤瘦？如何分析鏈路性能問題以及實時容量規(guī)劃宿礁？面對上面這些問題，Spring Cloud Sleuth提供了分布式服務(wù)跟蹤解決方案蔬芥。?

目錄：

一梆靖、為什么需要以及什么是分布式服務(wù)跟蹤系統(tǒng)

二、分布式服務(wù)跟蹤：SpringCloudSleuth

三笔诵、分布式服務(wù)跟蹤系統(tǒng)其他解決方案

一返吻、為什么需要以及什么是

分布式服務(wù)跟蹤系統(tǒng)

• 為什么需要分布式服務(wù)跟蹤系統(tǒng)

隨著分布式服務(wù)架構(gòu)的流行，特別是微服務(wù)等設(shè)計理念在系統(tǒng)中的應(yīng)用乎婿，業(yè)務(wù)的調(diào)用鏈越來越復(fù)雜测僵。

可以看到，隨著業(yè)務(wù)的發(fā)展谢翎，系統(tǒng)規(guī)模也會變得越來越大捍靠，各微服務(wù)間的調(diào)用關(guān)系也變得越來越復(fù)雜。通常一個由客戶端發(fā)起的請求在后端系統(tǒng)中會經(jīng)過多個不同的微服務(wù)調(diào)用來協(xié)同產(chǎn)生最后的請求結(jié)果森逮，在復(fù)雜的微服務(wù)架構(gòu)系統(tǒng)中榨婆，幾乎每一個前端請求都會形成一個復(fù)雜的分布式服務(wù)調(diào)用鏈路，在每條鏈路中任何一個依賴服務(wù)出現(xiàn)延遲過高或者錯誤都有可能引起請求最后的失敗褒侧。同時良风，缺乏一個自上而下全局的調(diào)用id，如何有效的進行相關(guān)的數(shù)據(jù)分析工作闷供？對于大型網(wǎng)站系統(tǒng)烟央，如淘寶、京東等電商網(wǎng)站这吻，這些問題尤其突出吊档。

• 什么是分布式服務(wù)跟蹤系統(tǒng)

分布式服務(wù)跟蹤是整個分布式系統(tǒng)中跟蹤一個用戶請求的過程（包括數(shù)據(jù)采集、數(shù)據(jù)傳輸唾糯、數(shù)據(jù)存儲怠硼、數(shù)據(jù)分析、數(shù)據(jù)可視化）移怯，捕獲此類跟蹤讓我們構(gòu)建用戶交互背后的整個調(diào)用鏈的視圖香璃，這是調(diào)試和監(jiān)控微服務(wù)的關(guān)鍵工具。Spring Cloud Sleuth是Spring Cloud為分布式服務(wù)跟蹤提供的解決方案舟误，有了它葡秒，我們可以：

• 提供鏈路追蹤，故障快速定位：可以通過調(diào)用鏈結(jié)合業(yè)務(wù)日志快速定位錯誤信息。

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

• 各個調(diào)用環(huán)節(jié)的可用性蹋岩、梳理服務(wù)依賴關(guān)系以及優(yōu)化

• 數(shù)據(jù)分析，優(yōu)化鏈路：可以得到用戶的行為路徑学少，匯總分析應(yīng)用在很多業(yè)務(wù)場景剪个。

下面我們來看一個典型的分布式系統(tǒng)請求調(diào)用過程，如下圖所示：

• 分布式服務(wù)跟蹤系統(tǒng)的設(shè)計

• 分布式服務(wù)跟蹤系統(tǒng)設(shè)計目標(biāo)

低入侵性版确，應(yīng)用透明：即作為也業(yè)務(wù)組件扣囊，應(yīng)當(dāng)盡可能少入侵或者無入侵其他業(yè)務(wù)系統(tǒng)，對于使用方透明绒疗，減少開發(fā)人員的負擔(dān)侵歇。

低損耗：服務(wù)調(diào)用埋點本身會帶來性能損耗，這就需要調(diào)用跟蹤的低損耗吓蘑，實際中還會通過配置采樣率的方式惕虑，選擇一部分請求去分析請求路徑。

大范圍部署士修，擴展性：作為分布式系統(tǒng)的組件之一枷遂，一個優(yōu)秀的調(diào)用跟蹤系統(tǒng)必須支持分布式部署，具備良好的可擴展性棋嘲。

• 埋點與生成日志

埋點即系統(tǒng)在當(dāng)前節(jié)點的上下文信息酒唉，可以分為客戶端埋點、服務(wù)端埋點沸移，以及客戶端和服務(wù)端雙向型埋點痪伦。埋點日志通常要包含以下內(nèi)容traceId、spanId雹锣、調(diào)用的開始時間网沾，協(xié)議類型、調(diào)用方ip和端口蕊爵，請求的服務(wù)名辉哥、調(diào)用耗時，調(diào)用結(jié)果攒射，異常信息等醋旦，同時預(yù)留可擴展字段，為下一步擴展做準(zhǔn)備会放；

• 收集和存儲日志（主要支持分布式日志采集的方案饲齐，同時增加MQ作為緩沖）

• 分析和統(tǒng)計調(diào)用鏈路數(shù)據(jù)，以及時效性

• 展現(xiàn)以及決策支持

二咧最、分布式服務(wù)跟蹤：

SpringCloudSleuth

• 快速入門

在引入Sleuth之前捂人，我們需要做一些準(zhǔn)備工作御雕，具體如下所示：

• 服務(wù)注冊中心（eureka-server）

• 微服務(wù)應(yīng)用分別為trace1和trace2（它們都有一個REST接口，其中trace1通過RestTemplate調(diào)用trace2的REST接口）

微服務(wù)應(yīng)用trace1和trace2項目基本一樣（除配置端口滥搭、應(yīng)用名稱和REST的Path）酸纲，以trace1為示例：

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

• 主要代碼：

• 配置文件

• 運行結(jié)果，日志沒有沒有跟蹤信息

我們在瀏覽器或者postman通過http：//localhost:8080/trace1,可以返回trace2相應(yīng)接口的內(nèi)容论熙，同時我們看到控制臺并沒有跟蹤信息打印福青，微服務(wù)應(yīng)用trace1和trace2的日志信息具體如下圖所示：

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

如何為上面的trace1和trace2添加服務(wù)跟蹤功能呢脓诡？SpringCloudSleuth對于此進行封裝，使得我們?yōu)閼?yīng)用增加服務(wù)跟蹤能力的操作非常簡單媒役，滿足前面所說設(shè)計目標(biāo)（低入侵祝谚，應(yīng)用透明），只需在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調(diào)用http：//localhost:8080/trace1,可以返回trace2相應(yīng)接口的內(nèi)容穿仪，同時我們看到控制臺日志已經(jīng)存在跟蹤信息席爽，微服務(wù)應(yīng)用trace1和trace2的日志信息具體如下圖所示：

從上面的控制臺輸出內(nèi)容中，我們看到多出了一些形如[trace1,454445a6a7d9ea44,912a7c66c17214e0,false]的日志信息啊片，而這些元素正是實現(xiàn)分布式服務(wù)跟蹤的重要組成部分只锻，它們的含義分別如下所示：

第一個值：trace1，它表示應(yīng)用的名稱紫谷，也就是配置文件spring.application.name的值齐饮。

第二個值：454445a6a7d9ea44，它是SpringCloudSleuth生成的一個ID笤昨，稱為Trace ID祖驱，它用來標(biāo)識一條請求鏈路，一條請求鏈路中包含一個Trace ID瞒窒，多個Span ID捺僻。

第三個值：912a7c66c17214e0，它是SpringCloudSleuth生成的另外一個ID崇裁，稱為Span ID匕坯，它表示一個基本的工作單元，比如發(fā)送一個http請求寇壳。

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

?

上面四個值中的Trace ID 和Span ID是SpringCloudSleuth實現(xiàn)分布式服務(wù)跟蹤的核心壳炎。在一次服務(wù)請求鏈路的調(diào)用過程中泞歉，會保持并傳遞同一個Trace ID逼侦，從而將整個分布于不同微服務(wù)進程中的請求跟蹤信息串聯(lián)起來。例如腰耙，在一次前端請求鏈路中榛丢，上面trace1和trace2的Trace ID是相同的。

• 跟蹤原理

分布式服務(wù)跟蹤系統(tǒng)主要包括下面三個關(guān)鍵點：

（1）Trace：它是由一組有相同Trace ID的Span串聯(lián)形成一個樹狀結(jié)構(gòu)挺庞。為了實現(xiàn)請求跟蹤晰赞，當(dāng)請求請求到分布式系統(tǒng)的入口端點時，只需要服務(wù)跟蹤框架為該請求創(chuàng)建一個唯一的跟蹤標(biāo)識（即前文提到的Trace ID）选侨，同時在分布式系統(tǒng)內(nèi)部流轉(zhuǎn)的時候掖鱼，框架始終保持傳遞該唯一標(biāo)識，直到返回請求為止援制，我們通過它將所有請求過程中的日志關(guān)聯(lián)起來戏挡；

（2）Span：它代表了一個基礎(chǔ)的工作單元，例如服務(wù)調(diào)用晨仑。為了統(tǒng)計各處理單元的時間延遲褐墅，當(dāng)前請求到達各個服務(wù)組件時，也通過一個唯一標(biāo)識（即前文提到的Span ID）來標(biāo)記它的開始洪己、具體過程以及結(jié)束妥凳。通過span的開始和結(jié)束的時間戳，就能統(tǒng)計該span的時間延遲答捕，除此之外逝钥，我們還可以獲取如事件名稱、請求信息等元數(shù)據(jù)噪珊。

（3）Annotation：它用于記錄一段時間內(nèi)的事件晌缘。內(nèi)部使用的最重要的注釋是：

• cs （Client Send）：客戶端發(fā)出請求，為開始跨度

• sr （Server Received）：服務(wù)器已收到請求并開始處理痢站。timestampsr - timestampcs =網(wǎng)絡(luò)延遲磷箕。

• ss （Server Send）：服務(wù)器處理完畢準(zhǔn)備發(fā)送到客戶端。timestampss - timestampsr =服務(wù)器上的請求處理時間阵难。

• cr （Client Received）：客戶端接收到服務(wù)器響應(yīng)岳枷，為跨度結(jié)束∥亟校客戶端已成功接收到服務(wù)器的響應(yīng)空繁。timestampcr - timestampcs =請求的總時間。

以下是在使用Sleuth的兩個微服務(wù)之間的調(diào)用中請求的行為方式朱庆，除了生成唯一標(biāo)識符并將其添加到應(yīng)用程序日志之外盛泡，還需要在作為請求的一部分的微服務(wù)器之間正確傳播它們。

• 抽樣收集

我們在對接分析系統(tǒng)時就會碰到一個問題：分析系統(tǒng)在收集跟蹤信息的時候娱颊，需要收集多少跟蹤信息才合適呢傲诵？生產(chǎn)環(huán)境與開發(fā)環(huán)境跟蹤信息收集比例應(yīng)該不一致凯砍，我們是否可以調(diào)整呢？同時拴竹，不同業(yè)務(wù)系統(tǒng)收集比例可能也不一樣悟衩。

理論上來說，我們收集的跟蹤信息越多就可以越好反映出系統(tǒng)的實際運行情況栓拜，并給出更精確的預(yù)警和分析座泳。但在高并發(fā)的分布式系統(tǒng)運行時，大量的請求調(diào)用會產(chǎn)生海量的跟蹤日志信息幕与，如果收集過多的跟蹤信息將會對整個分布式系統(tǒng)的性能造成一定的影響挑势，同時保存大量的日志信息也需要不少的存儲開銷。所以啦鸣，在Sleuth中采用了抽象收集的方式來跟蹤信息打上標(biāo)記薛耻，也就是我們前面第四個布爾值，它代表了該信息是否要被后續(xù)的跟蹤信息收集器獲取和存儲赏陵。

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

• 與ELK整合

前面隨著已經(jīng)有了跟蹤信息吃型，但是由于日志文件都分布在各個服務(wù)實例的文件系統(tǒng)上，如果鏈路上服務(wù)比較多僚楞，查看日志文件定位問題是一件非常麻煩的事情勤晚，所以我們需要一些工具來幫忙集中收集、存儲和搜素這些跟蹤信息泉褐。引入基于日志的分析系統(tǒng)是一個不錯的選擇赐写，比如ELK平臺，SpringCloudSleuth在與ELK平臺整合使用時膜赃，實際上只需要與負責(zé)日志收集的Logstash完成數(shù)據(jù)對接即可挺邀，所以我們需要為logstash準(zhǔn)備Json格式的日志輸出（SpringBoot應(yīng)用默認(rèn)使用logback來記錄日志，而logstash自身也有對logback日志工具支持）跳座。與ELK整合架構(gòu)圖如下所示：

• 與Zipkin整合

雖然通過ELK平臺提供的收集端铛、存儲、搜索等強大功能疲眷，但是缺少對請求鏈路中各階段時間延遲的關(guān)注禾蚕，而很多時候我們追溯請求鏈路的一個原因是為了找出整個鏈路中出現(xiàn)延遲過高的瓶頸源，或者找出問題服務(wù)實例等監(jiān)控與時間消耗相關(guān)的需求狂丝，ELK就顯得乏力换淆，反而引入Zipkin就能夠輕松解決哗总。

Zipkin是Twitter的一個開源項目，它基于Google Dapper實現(xiàn)产舞。我們可以使用它來收集各個服務(wù)器上請求鏈路的跟蹤數(shù)據(jù)魂奥，并通過它提供的Rest API接口來輔助查詢跟蹤數(shù)據(jù)以分布式系統(tǒng)的監(jiān)控程序，通過UI組件幫助我們及時發(fā)現(xiàn)系統(tǒng)中出現(xiàn)的延遲升高問題以及系統(tǒng)性能瓶頸根源易猫。下面展示Zipkin的基礎(chǔ)架構(gòu)耻煤，它主要由4個核心組件構(gòu)成：

Collector（收集器組件）：主要負責(zé)收集外部系統(tǒng)跟蹤信息，轉(zhuǎn)化為Zipkin內(nèi)部的Span格式准颓。

Storage（存儲組件）：主要負責(zé)收到的跟蹤信息的存儲哈蝇，默認(rèn)為內(nèi)存，同時支持存儲到Mysql攘已、Cassandra以及Elasticsearch炮赦。

Restful API（API組件）：提供接口，方便外部系統(tǒng)進行集成样勃。

Web UI（展示組件）：基于API開發(fā)的自帶展示界面吠勘，方便進行跟蹤信息的查看以及查詢，同時進行相關(guān)的分析峡眶。

與zipkin整合——HTTP收集

sleuth收集跟蹤信息通過http請求發(fā)送給zipkin server剧防，zipkinserver進行跟蹤信息的存儲以及提供Rest API即可，Zipkin UI調(diào)用其API接口進行數(shù)據(jù)展示辫樱。其大體路流程如下圖所示：

代碼如何實現(xiàn)呢峭拘？主要有兩個部分：搭建Zipkin Server、為應(yīng)用引入zipkin依賴和配置狮暑，具體如下所示：

（1）搭建Zipkin Server

添加Pom依賴

主要代碼

配置文件

（2）為應(yīng)用引入zipkin依賴和配置

添加Pom依賴

為應(yīng)用增加配置文件

啟動Zipkin Server以及分別重啟trace1和trace2鸡挠，再次通過瀏覽器或者postman調(diào)用http：//localhost:8080/trace1,可以返回trace2相應(yīng)接口的內(nèi)容，同時我們看到控制臺日志已經(jīng)存在跟蹤信息搬男，然后通過瀏覽器訪問http：//localhost:9411/,我們可以看到Zipkin對于跟蹤信息分析與展示拣展，可以看到請求鏈路，以及每個span的具體耗時止后，就能分析進行鏈路優(yōu)化瞎惫、依賴分析等操作，其界面具體如下所示：

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

Spring Cloud Sleuth在整合Zipkin時译株，不僅實現(xiàn)了以Http的方式收集瓜喇，還實現(xiàn)了通過消息中間件來對跟蹤信息進行異步收集。通過結(jié)合Spring Cloud Stream歉糜，我們可以非常輕松地讓應(yīng)用客戶端將跟蹤信息輸出到消息中間件乘寒，同時Zipkin服務(wù)端從消息中間件上異步獲取這些跟蹤信息，具體如下所示：

代碼如何實現(xiàn)呢匪补？主要有兩個部分：搭建Zipkin Server伞辛、為應(yīng)用引入zipkin依賴和配置烂翰，具體如下所示：

（1）搭建Zipkin Server

添加Pom依賴

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

配置文件

（2）為應(yīng)用引入zipkin依賴和配置

添加Pom依賴

為應(yīng)用增加配置文件

與Zipkin整合——數(shù)據(jù)存儲

默認(rèn)情況下，Zipkin Server會將跟蹤信息存儲在內(nèi)存中蚤氏，但是這樣就會出現(xiàn)我們重啟Zipkin Server時之前收集的跟蹤信息丟失的問題甘耿。為了解決此問題，Zipkin提供了多種存儲方式竿滨，比如Mysql佳恬、Cassandra以及Elasticsearch，以Mysql為例于游，我們能夠很輕松地為Zipkin Server增加Mysql存儲功能毁葱。主要有三個步驟即可：第一步，在Mysql中創(chuàng)建數(shù)據(jù)庫并且運行其數(shù)據(jù)腳本贰剥；第二步倾剿，為pom添加數(shù)據(jù)庫依賴；第三步蚌成，修改配置更換存儲方式前痘。更多內(nèi)容請我另一篇博客《微服務(wù)之分布式跟蹤系統(tǒng)（springboot+zipkin）》。

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

與Zipkin整合——API接口

Zipkin不僅提供了Web UI方便用戶進行跟蹤信息查看與查詢担忧，同時還提供了Rest API际度，方便第三方系統(tǒng)進行集成進行跟蹤信息的展示和監(jiān)控，其提供的API列表如下所示：

三涵妥、分布式服務(wù)跟蹤系統(tǒng)其他解決方案

OpenTracing通過提供平臺無關(guān)、廠商無關(guān)的API坡锡，使得開發(fā)人員能夠方便的添加（或更換）追蹤系統(tǒng)的實現(xiàn)蓬网。 OpenTracing提供了用于運營支撐系統(tǒng)的和針對特定平臺的輔助程序庫。下面為其相應(yīng)的成員以及提供的產(chǎn)品：

分布式服務(wù)跟蹤系統(tǒng)其他解決方案：Jaeger

Jaeger（https://github.com/jaegertracing/jaeger）受到Dapper和Zipkin的啟發(fā)鹉勒，從開始就建立了OpenTracing支持帆锋，是由Uber Technologies作為開源發(fā)布的分布式跟蹤系統(tǒng)。它可用于監(jiān)控基于微服務(wù)的體系結(jié)構(gòu)：分布式上下文傳播禽额、分布式事務(wù)監(jiān)控锯厢、根本原因分析、服務(wù)依賴性分析以及性能/延遲優(yōu)化脯倒。其架構(gòu)圖如下所示：

分布式服務(wù)跟蹤系統(tǒng)其他解決方案： Sky Walking

Skywalking （https://github.com/wu-sheng/sky-walking）全鏈路監(jiān)控開源項目实辑，也是唯一的國內(nèi)團隊開源的APM監(jiān)控項目。其架構(gòu)圖如下所示：

最后藻丢，附上文章所講內(nèi)容的源碼下載地址（源碼地址：https://github.com/dreamerkr/SpringCloudSleuthExample.git ）剪撬，需要可以進行下載與交流。

關(guān)于作者：

王召

現(xiàn)任普元信息資深開發(fā)工程師悠反，為普元新一代數(shù)字化企業(yè)云平臺開發(fā)團隊一員残黑，負責(zé)新一代SPM（軟件產(chǎn)品管理）與MKT（軟件市場）領(lǐng)域系統(tǒng)的開發(fā)馍佑。曾在百度西北營銷自主研發(fā)中心、格林談?wù)効萍嫉然ヂ?lián)網(wǎng)公司從事開發(fā)經(jīng)理工作梨水，曾主導(dǎo)開發(fā)過多款電商和社交項目拭荤，并獲得風(fēng)險基金的投資。平時喜歡旅游疫诽，騎行舅世，爬山等活動。

關(guān)于EAWorld

微服務(wù)踊沸，DevOps歇终，元數(shù)據(jù)，企業(yè)架構(gòu)原創(chuàng)技術(shù)分享逼龟，EAii（Enterprise?Architecture?Innovation?Institute）企業(yè)架構(gòu)創(chuàng)新研究院旗下官方微信公眾號评凝。

微信號：eaworld，長按二維碼關(guān)注

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