一篇帶給你Spring Cloud Sleuth入門介紹
前言Hi,大家好,我是麥洛,今天帶大家來了解一下SpringCloud Sleuth,這篇文章主要向大家介紹一下以下內(nèi)容
Sleuth介紹
你或許曾經(jīng)聽過這么一句話,一個(gè)新技術(shù)的出現(xiàn)是為了解決一個(gè)痛點(diǎn)問題。在介紹Sleuth之前,我們需要了解一下在沒有Sleuth之前,我們的微服務(wù)遇到了什么問題?
1.微服務(wù)的現(xiàn)狀?
前段時(shí)間在一個(gè)交流群吹水,一個(gè)大佬說他們公司總共有上百個(gè)微服務(wù)。假如這句話真實(shí)，那么他們公司微服務(wù)調(diào)用可能會如下圖所示:
來自網(wǎng)絡(luò)的這張圖很好的說明了微服務(wù)調(diào)用之間的復(fù)雜性。每一次前端請求往往需要涉及到多個(gè)服務(wù)。這些服務(wù)有可能是由不同的團(tuán)隊(duì)開發(fā)、可能使用不同的編程語言來實(shí)現(xiàn)、有可能布在了幾千臺服務(wù)器，橫跨多個(gè)不同的數(shù)據(jù)中心。因此，就需要一些可以幫助理解系統(tǒng)行為、用于分析性能問題的工具，以便發(fā)生故障的時(shí)候，能夠快速定位和解決問題。所以，鏈路追蹤這個(gè)思想就被人提了出來，而我們今天要討論的Sleuth就是借鑒該思想演變來的分布式追蹤解決方案。
2.微服務(wù)跟蹤解決了什么問題?
微服務(wù)跟蹤(sleuth)其實(shí)是一個(gè)工具,它在整個(gè)分布式系統(tǒng)中能跟蹤一個(gè)用戶請求的過程(包括數(shù)據(jù)采集，數(shù)據(jù)傳輸，數(shù)據(jù)存儲，數(shù)據(jù)分析，數(shù)據(jù)可視化)，捕獲這些跟蹤數(shù)據(jù)，就能構(gòu)建微服務(wù)的整個(gè)調(diào)用鏈的視圖，這是調(diào)試和監(jiān)控微服務(wù)的關(guān)鍵工具。SpringCloudSleuth有4個(gè)特點(diǎn)
Sleuth基本術(shù)語
Spring Cloud Sleuth采用的是Google的開源項(xiàng)目Dapper的專業(yè)術(shù)語。
- Span：基本工作單元，發(fā)送一個(gè)遠(yuǎn)程調(diào)度任務(wù) 就會產(chǎn)生一個(gè)Span，Span是一個(gè)64位ID唯一標(biāo)識的，Trace是用另一個(gè)64位ID唯一標(biāo)識的，Span還有其他數(shù)據(jù)信息，比如摘要、時(shí)間戳事件、Span的ID、以及進(jìn)度ID。
- Trace：一系列Span組成的一個(gè)樹狀結(jié)構(gòu)。請求一個(gè)微服務(wù)系統(tǒng)的API接口，這個(gè)API接口，需要調(diào)用多個(gè)微服務(wù)，調(diào)用每個(gè)微服務(wù)都會產(chǎn)生一個(gè)新的Span，所有由這個(gè)請求產(chǎn)生的Span組成了這個(gè)Trace。
- Annotation：用來及時(shí)記錄一個(gè)事件的，一些核心注解用來定義一個(gè)請求的開始和結(jié)束 。這些注解包括以下：
- cs - Client Sent -客戶端發(fā)送一個(gè)請求，這個(gè)注解描述了這個(gè)Span的開始
- sr - Server Received -服務(wù)端獲得請求并準(zhǔn)備開始處理它，如果將其sr減去cs時(shí)間戳便可得到網(wǎng)絡(luò)傳輸?shù)臅r(shí)間。
- ss - Server Sent (服務(wù)端發(fā)送響應(yīng))–該注解表明請求處理的完成(當(dāng)請求返回客戶端)，如果ss的時(shí)間戳減去sr時(shí)間戳，就可以得到服務(wù)器請求的時(shí)間。
- cr - Client Received (客戶端接收響應(yīng))-此時(shí)Span的結(jié)束，如果cr的時(shí)間戳減去cs時(shí)間戳便可以得到整個(gè)請求所消耗的時(shí)間。
Sleuth入門案例
首先我們搞一個(gè)項(xiàng)目,大概如下面樣子
我們引入下面的依賴
- <dependencies>
- <dependency>
- <groupId>org.springframework.boot</groupId>
- <artifactId>spring-boot-starter-web</artifactId>
- </dependency>
- <!--關(guān)鍵依賴-->
- <dependency>
- <groupId>org.springframework.cloud</groupId>
- <artifactId>spring-cloud-starter-sleuth</artifactId>
- </dependency>
- <dependency>
- <groupId>org.projectlombok</groupId>
- <artifactId>lombok</artifactId>
- </dependency>
- <dependency>
- <groupId>org.springframework.boot</groupId>
- <artifactId>spring-boot-starter-test</artifactId>
- <scope>test</scope>
- <exclusions>
- <exclusion>
- <groupId>org.junit.vintage</groupId>
- <artifactId>junit-vintage-engine</artifactId>
- </exclusion>
- </exclusions>
- </dependency>
我們創(chuàng)建一個(gè)測試類:
- package com.milo.sleuth.controller;
- import lombok.extern.slf4j.Slf4j;
- import org.springframework.web.bind.annotation.RequestMapping;
- import org.springframework.web.bind.annotation.RestController;
- @RestController
- @Slf4j
- public class Example {
- @RequestMapping("/")
- String home() {
- log.info("Hello world!");
- return "Hello World!";
- }
- }
啟動項(xiàng)目以后,我們訪問一下:
這時(shí)候,我們來看看日志情況:
我們來看看它們分別代表什么意思
- 第一個(gè)就是我們服務(wù)名稱,對應(yīng)我們配置文件中的spring.application.name
- 第二個(gè)就是traceId
- 第三個(gè)就是spanId
雖然我們現(xiàn)在通過日志文件也可以識別調(diào)用路徑,貌似并不是很方便,很直觀,接下里我們來了解一下Zipkin
Zipkin介紹
Zipkin是一個(gè)分布式跟蹤系統(tǒng)。它有助于收集解決服務(wù)體系結(jié)構(gòu)中的延遲問題所需的時(shí)序數(shù)據(jù)。功能包括該數(shù)據(jù)的收集和查找。
如果您在日志文件中有跟蹤ID，則可以直接跳至該跟蹤ID。否則，您可以基于諸如服務(wù)，操作名稱，標(biāo)簽和持續(xù)時(shí)間之類的屬性進(jìn)行查詢。將為您匯總一些有趣的數(shù)據(jù)，例如服務(wù)中花費(fèi)的時(shí)間百分比以及操作是否失敗。
Zipkin UI還提供了一個(gè)依賴關(guān)系圖，該關(guān)系圖顯示了每個(gè)應(yīng)用程序中跟蹤了多少個(gè)請求。這對于識別包括錯(cuò)誤路徑或?qū)Σ毁澇墒褂玫姆?wù)的調(diào)用在內(nèi)的匯總行為可能會有所幫助。
需要對應(yīng)用程序進(jìn)行“儀表化”以將跟蹤數(shù)據(jù)報(bào)告給Zipkin。這通常意味著配置跟蹤器或儀器庫。向Zipkin報(bào)告數(shù)據(jù)的最流行方法是通過HTTP或Kafka，盡管存在許多其他選項(xiàng)，例如Apache ActiveMQ，gRPC和RabbitMQ。提供給UI的數(shù)據(jù)存儲在內(nèi)存中，或持久存儲在受支持的后端(例如Apache Cassandra或Elasticsearch)中。
Sleuth整合Zipkin
Zipkin 分為兩端，一個(gè)是 Zipkin 服務(wù)端，一個(gè)是 Zipkin 客戶端，客戶端也就是微服務(wù)的應(yīng)用，客戶端會配置服務(wù)端的 URL 地址，一旦發(fā)生服務(wù)間的調(diào)用的時(shí)候，會被配置在微服務(wù)里面的 Sleuth 的監(jiān)聽器監(jiān)聽，并生成相應(yīng)的 Trace 和 Span 信息發(fā)送給服務(wù)端。發(fā)送的方式有兩種，一種是消息總線的方式如 RabbitMQ 發(fā)送，還有一種是 HTTP 報(bào)文的方式發(fā)送。
客戶端
首先,在剛剛的依賴文件中,我們加一個(gè)新成員
- <dependency>
- <groupId>org.springframework.cloud</groupId>
- <artifactId>spring-cloud-starter-zipkin</artifactId>
- </dependency>
接著修改配置文件
- # 應(yīng)用名稱
- spring:
- application:
- name: springcloud-sleuth
- # 應(yīng)用服務(wù) WEB 訪問端口
- server:
- port: 9876
- zipkin:
- base-url: http://localhost:9411/ # 服務(wù)端地址
- sender:
- type: web # 數(shù)據(jù)傳輸方式，web 表示以 HTTP 報(bào)文的形式向服務(wù)端發(fā)送數(shù)據(jù)
- sleuth:
- sampler:
- probability: 1.0 # 收集數(shù)據(jù)百分比，默認(rèn) 0.1（10%）
服務(wù)端
Zipkin的服務(wù)端是一個(gè)可執(zhí)行的jar文件,我們需要去下載
- “下載地址:https://search.maven.org/remote_content?g=io.zipkin&a=zipkin-server&v=LATEST&c=exec
上面地址默認(rèn)下載最新版本,大家也可以去下面的網(wǎng)址下載指定版本
現(xiàn)在我們啟動jar包
- “java -jar zipkin-server-2.23.2-exec.jar
測試效果
接下來我們訪問一下http://localhost:9411/zipkin/,結(jié)果如下:
環(huán)境搭架好了,現(xiàn)在我們測試一把,看看接入Zipkin之后,我們會看到什么效果?
我們訪問http://localhost:9876/之后,點(diǎn)擊Zipkin控制臺的Run Query查詢一下,看到如下效果:
繼續(xù)點(diǎn)擊show,我們?nèi)タ纯丛斍?/p>
果然很強(qiáng)大,執(zhí)行時(shí)間,什么請求方式,請求路徑,那個(gè)類,那個(gè)方法一目了然
鑒于我們剛剛新建的只是一次很簡單的調(diào)用,不足以模擬微服務(wù)場景,接下來我們來看一個(gè)復(fù)雜一點(diǎn)的場景;
這里為了偷懶,我們就不去創(chuàng)建自己的微服務(wù),使用官方給我們提供的測試案例brave-example,如下所示
我們把代碼搞下來,這個(gè)項(xiàng)目好像整合了好多技術(shù)的測試案例,看不懂,我就研究了下面的這個(gè)跑起來測試一下
我們用idea把這個(gè)項(xiàng)目導(dǎo)入進(jìn)來,大概長這個(gè)鬼樣子
- Backend代表后端服務(wù)
- Frontend代表前端服務(wù)
現(xiàn)在,我們首先保證我們Zipkin的服務(wù)端是ok的,這時(shí)候你首先啟動后端服務(wù),然后啟動前端服務(wù),其實(shí)就是執(zhí)行以下main方法,接下來我們訪問一下http://127.0.0.1:8081/,如下圖所示
現(xiàn)在我們?nèi)ipkin查詢一下,發(fā)現(xiàn)了一個(gè)新大陸,開心
就行show一下,看看里面啥情況
總結(jié)
本篇文章主要介紹了Sleuth的入門知識,并且整合Zipkin來可視化顯示調(diào)用鏈路的整體情況,但是目前Zipkin數(shù)據(jù)存在于內(nèi)存中,我們可以在接入Elasticsearch等工具來做數(shù)據(jù)持久化。謝謝大家，今天的分享就到這里。
- 源碼 https://gitee.com/milogenius/milogenius-springcloud
- 模塊:springcloud-sleut
