Spring Cloud 專題之七:Sleuth 服務跟踪

pluto_charon 2021-08-15 14:56:52 阅读数:743

本文一共[544]字,预计阅读时长:1分钟~
spring cloud sleuth 跟踪

書接上回:

SpringCloud專題之一:Eureka

Spring Cloud專題之二:OpenFeign

Spring Cloud專題之三:Hystrix

Spring Cloud 專題之四:Zuul網關

Spring Cloud專題之五:config

Spring Cloud 專題之六:bus

在一個微服務架構中,系統的規模往往會比較大,各微服務之間的調用關系也錯綜複雜。通常一個有客戶端發起的請求在後端系統中會經過多個不同的微服務調用阿裏協同產生最後的請求結果。在複雜的微服務架構中,幾乎每一個前端請求都會形成一條複雜的分布式的服務調用鏈路,在每條鏈路中任何一個依賴服務出現延遲過高或錯誤的時候都有可能引起請求最後的失敗。

這個時候,對於每個請求,全鏈路調用的跟踪就邊得越來越重要,通過實現對請求調用的跟踪可以幫助我們快速發現問題根源以及監控分析每條請求鏈路上的性能瓶頸等。而Spring Cloud Sleuth就是一個提供了一套完整的解决方案的組件。

在開始今天的這個例子之前,可以看一下我之前的幾篇博客,特別是hystrix之前的博客。本篇博客就是在這基礎上所增加的新功能。在之前的實踐中,通過9004的customer-server項目調用9003的hello-server項目的接口。

准備工作

在之前的服務調用的方法上加上日志操作。

customer-server的CustomerController類:

@RequestMapping("/sayHello1")
@ResponseBody
public String invokeSayHello1(String name){
logger.info("調用了customer-server的sayHello1方法,參數為:{}",name);
return serivce.invokeSayHello1(name);
}

hello-server的Hello1Controller類:

@RequestMapping("/sayHello1")
public String sayHello1(@RequestParam("name") String name){
logger.info("你好,服務名:{},端口為:{},接收到的參數為:{}",instanceName,host,name);
try {
int sleepTime = new Random().nextInt(3000);
logger.error("讓線程阻塞 {} 毫秒",sleepTime);
Thread.sleep(sleepTime);
} catch (InterruptedException e) {
e.printStackTrace();
}
return "你好,服務名:"+instanceName+",端口為:"+host+",接收到的參數為:"+name;
}

在頁面上訪問localhost:9004/sayHello1?name=charon

# customer-server中的打印日志
2021-08-09 23:22:33.905 INFO 19776 --- [nio-9004-exec-8] c.c.e.controller.CustomerController : 調用了customer-server的sayHello1方法,參數為:charon
# hello-server中的打印日志
2021-08-09 23:22:33.917 INFO 2884 --- [nio-9003-exec-9] c.c.e.controller.Hello1Controller : 你好,服務名:hello-server,端口為:9003,接收到的參數為:charon

實現跟踪

在修改完上面的代碼後,為customer-server項目和hello-server項目添加服務跟踪的功能,引入依賴

<!--引入sleuth鏈路追踪的jar包-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

頁面調用查看日志:

# customer-server中的打印日志
2021-08-09 23:30:44.782 INFO [customer-server,0e307552774ef605,0e307552774ef605,true] 14616 --- [nio-9004-exec-2] c.c.e.controller.CustomerController : 調用了customer-server的sayHello1方法,參數為:charon
# hello-server中的打印日志
2021-08-09 23:30:44.807 INFO [hello-server,0e307552774ef605,4cf4d9dd57ca7478,true] 6660 --- [nio-9003-exec-2] c.c.e.controller.Hello1Controller : 你好,服務名:hello-server,端口為:9003,接收到的參數為:charon

從上面的控制臺的輸出內容可以看到形如[customer-server,0e307552774ef605,0e307552774ef605,true] 的日志信息,而浙西而元素正是實現分布式服務跟踪的重要組成部分,每個值的含義如下:

  • customer-server:應用的名稱,也就是application.properties中的soring。application.name的值
  • 0e307552774ef605:Spring Cloud Sleuth生成的一個ID,成微Trace ID,它用來標識一條請求鏈路,一條請求鏈路中包含一個Trace ID,多個Span ID。
  • 0e307552774ef605:Spring Cloud Sleuth生成的另一個ID,成為Span ID,它錶識一個基本的工作單元,比如發慫一個HTTP請求
  • true:錶示是否要將改信息輸出到Zipkin等服務中來收集和展示

在一個服務請求鏈路的調用過程中,會包吃並傳遞同一個Trace ID,從而將整個分布於不容微服務進程中的請求跟踪信息串聯起來。以上面輸出內容為例,customer-server和hello-server同屬於一個前端服務請求來源,所以他們的Trace ID是相同的,處於同一個請求鏈路中。通過Trace ID,我們就能將所有請求過程的日志關聯起來。

在Spring Boot應用中,通過引入spring-cloud-starter-sleuth依賴之後,他會自動為當前應用構建起通道跟踪機制,比如:

  • 通過RabbitMQ,Kafka等中間件傳遞的請求
  • 通過Zuul代理傳遞的請求
  • 通過RestTemplate發起的請求。

抽樣收集

通過TraceID和SpanID已經實現了對分布式系統中的請求跟踪,而記錄的跟踪信息最終會被分析系統收集起來,並用來實現對分布式系統的監控和分析功能。

理論上講,收集的跟踪信息越多就可以越好的反應系統的真實運行情况,並給出更精准的預警和分析,但是在高並發的分布式系統運行時,大兩的請求調用會產生海量的跟踪日志信息,如果收集過多對整個系統的性能也會造成一定的影響,同時保存大兩的日志信息也需要很大的存儲開銷。所以在Sleuth中菜用了抽樣收集的方式來為跟踪信息打商收集標記。也就是我們之前在日志信息中看到的第4個布爾類型的值,它代錶了改信息是否要改後續的跟踪信息收集器獲取或存儲。

默認情况下,Sleuth會使用 zipkin brave的ProbabilityBasedSampler的抽樣策略(現在已經不推薦使用),即以請求百分比的方式配置和收集跟踪信息,我們可以在配置文件中配置參數對其百分比值進行設置(它的默認值為 0.1,代錶收集 10% 的請求跟踪信息)。

spring.sleuth.sampler.probability=0.5

而如果在配置文件中配置了 spring.sleuth.sampler.rate 的屬性值,那麼便會使用zipkin Brave自帶的RateLimitingSampler的抽樣策略。不同於ProbabilityBasedSampler菜用概况收集的策略,RateLimitingSampler是菜用的限速收集,也就是說它可以用來限制每秒跟踪請求的最大數量。

  • 如果同時設置了 spring.sleuth.sampler.ratespring.sleuth.sampler.probability 屬性值,也仍然使用 RateLimitingSampler 抽樣策略(即 spring.sleuth.sampler.probability 屬性值無效)
  • RateLimitingSampler 策略每秒間隔接受的 trace 量設置範圍:最小數字為 0,最大值為 2,147,483,647(最大 int

整合Zipkin

Zipkin是twitter的一個開源項目,它基於Google Dapper實現,我們可以用它來實現收集各個服務器上的請求鏈路的跟踪。並通過它提供的REST API接口來輔助查詢跟踪數據以實現對分布式系統的監控程序,從而及時發現系統中出現的延遲昇高問題並找出系統性能瓶頸的根源。同時,Zipkin還提供了方便的UI組件來幫助我們直觀地所搜跟踪信息和分析請求地鏈路明細,比如可以查詢某段時間內各用戶請求地處理時間等。

Spring Boot 2.x 以後官網不推薦使用源碼方式編譯,推薦使用官網編譯好的jar執行。所以我們不熟Zipkin也使用jar包的方式。

1.下載Zipkin

我這裏是到maven倉庫中下載的。

https://search.maven.org/remote_content?g=io.zipkin.java&a=zipkin-server&v=LATEST&c=exec

下載完成後,使用java -jar命令啟動zipkin。

2.引入依賴配置

為customer-server和hello-server的項目引入zipkin的包:

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-sleuth-zipkin</artifactId>
</dependency>

配置文件添加zipkin的地址:

spring.zipkin.base-url=http://localhost:9411

3.測試與分析

完成所有接入Zipkin的工作後,依次講服務起來,瀏覽器發送請求做測試。

點擊查找按鈕,下方出現服務調用的信息。注意,只有在sleuth的最後一個參數為true的時候,才會講改跟踪信息輸出給Zipkin Server。

單擊其中的某一個,還可以得到Sleuth跟踪到的詳細信息。其中就包括時間請求時間消耗等。

單擊導航欄中的依賴按鈕,還可以查看到Zipkin根據跟踪信息分析生成的系統關系請求鏈路依賴關系圖。

持久化到mysql

在SpringBoot2.0之前的版本,Zipkin-Server端由我們自己創建項目來搭建。可以比較靈活的選擇數據持久化的配置,SpringBoot2.0之後的版本,Zipkin-Server端由官方提供,無需我們自己搭建,那麼如何選擇去配置將數據持久化到MySQL呢?

1.創建zipkin數據庫

在下載好的zipkin-serve的jar包中,找到zipkin-server-shared.yml的文件,

在裏面可以找到關於mysql的持久化配置,可以看到數據庫名稱默認為zipkin,

初始化mysql的脚本:https://github.com/openzipkin/zipkin/blob/master/zipkin-storage/mysql-v1/src/main/resources/mysql.sql

創建的數據庫如下:

2.啟動zipkin

在啟動zipkin的時候,以命令行的方式啟動,輸入mysql的參數

java -jar zipkin-server-2.12.9-exec.jar --STORAGE_TYPE=mysql --MYSQL_HOST=127.0.0.1 --MYSQL_TCP_PORT=3306 --MYSQL_DB=zipkin --MYSQL_USER=root --MYSQL_PASS=root

3.測試與分析

瀏覽器訪問,因為我這次調用服務超時了,觸發了hystrix的斷路器功能,所以這次有8個span。

關閉zipkin-server,然後重啟,發現依然能够查詢到上一次請求的服務鏈路跟踪數據。查看數據庫錶,發現數據都存儲到錶裏了。

參考文章:

翟永超老師的《Spring Cloud微服務實戰》

https://www.hangge.com/blog/cache/detail_2803.html

https://blog.csdn.net/Thinkingcao/article/details/104957540

版权声明:本文为[pluto_charon]所创,转载请带上原文链接,感谢。 https://gsmany.com/2021/08/20210815145631827n.html