简述： 一个请求跨越了多少个微服务，各服务花费了多少时间，发现某个服务特别慢，直接将其降级使用 Spring Sleuth + Zipkin 搭配使用

Spring Sleuth: 追踪操作

Zipkin： 可视化

就是每到达一个节点都会记录时间，然后计算差值就可以得到传输时间，某个节点处理请求的时间

一、概念

官方文档：https://cloud.spring.io/spring-cloud-static/spring-cloud-sleuth/2.1.3.RELEASE/single/spring-cloud-sleuth.html![1599524692313](https://oss.imoyt.top/img/202206262254717.png)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
1、为什么用
微服务架构是一个分布式架构，它按业务划分服务单元，一个分布式系统往往有很多个服务
单元。由于服务单元数量众多，业务的复杂性，如果出现了错误和异常，很难去定位。主要
体现在，一个请求可能需要调用很多个服务，而内部服务的调用复杂性，决定了问题难以
定位。所以微服务架构中,必须实现分布式链路追踪,去跟进一个请求到底有哪些服务参与，
参与的顺序又是怎样的，从而达到每个请求的步骤清晰可见，出了问题，很快定位。
链路追踪组件有Google的Dapper，Twitter的Zipkin，以及阿里的Eagleeye（鹰眼）等，它
们都是非常优秀的链路追踪开源组件。

2、基本术语
	Span（跨度），基本工作单元，发送一个远程调度任务就会产生一个Span，Span是一个64位ID唯一标识的，Trace是用另一个64位ID唯一标识的，Span还有其他数据信息，比如摘要、时间戳事件、Span的ID、以及进度ID。

	Trace(跟踪):一系列Span组成的一个树状结构。请求一个微服务系统的AP接口，这个AP接口，需要调用多个微服务，调用每个微服务都会产生一个新的Span，所有由这个请求产生的Span组成了这个Traceo

	Annotation(标注）:用来及时记录一个事件的，一些核心注解用来定义一个请求的开
始和结束。这些注解包括以下:
	cs - Client Sent-客户端发送一个请求，这个注解描述了这个Span 的开始
	sr-Server Received -服务端获得请求并准备开始处理它,如果将其5r减去cs时间戳便可得到网络传输的时间。
	ss- Server Sent（服务端发送响应）–该注解表明请求处理的完成(当请求返回客户端)，如果ss的时间戳减去sr时									间戳，就可以得到服务器请求的时间。
	cr-Client Received（客户端接收响应）-此时Span的结束，如果cr,的时间戳减去cs时间戳便可以得到整个请求										所消耗的时间。

二、整合 Sleuth

在 common 中导入依赖

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<!-- 引入链路追踪sleuth -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>${spring-cloud.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

开启 debug

​ 在 product 和 seckill 服务开启

1
2
3
#开启服务追踪debug日志
logging.level.org.springframework.cloud.openfeign=debug
logging.level.org.springframework.cloud.sleuth=debug

访问看控制台： http://item.gulimall.com/6.html

image-20220627225259303

三、整合 ZipKin 可视化

通过 Sleuth 产生的调用链监控信息，可以的知微服务之间的调用链路，但监控信息只输出，到控制台不方便查看。我们需要一个图形的工具 zipkin。zipkin 是 Twitter 开源的分布式跟踪系统，主要用收集系统的时序数据，从而追踪系统的调用问题。zipkin 官网地址如下: https://zipkin.io/

1、安装 zipkin 服务器

1
docker run -d -p 9411:9411 openzipkin/zipkin

2、依赖

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<properties>
    <java.version>1.8</java.version>
    <spring-cloud.version>Greenwich.SR3</spring-cloud.version>
</properties>

<!--链路追踪可视化，包含了sleuth的依赖-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>


<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>${spring-cloud.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

3、配置

1
2
3
4
5
6
7
8
#链路追踪可视化zipkin服务器
spring.zipkin.base-url=http://192.168.56.10:9411/
#关闭服务发现，否则spring cloud会把zipkin的url当做服务名称
spring.zipkin.discovery-client-enabled=false
#设置使用http的方式传输数据
spring.zipkin.sender.type=web
#设置抽样采集率为100%，默认0.1
spring.sleuth.sampler.probability=1

4、访问http://192.168.56.10:9411/zipkin/
查看超过 100ms 的请求，是否可以优化
结合 zipkin 找到慢请求，该降级的降级，该限流的限流

image-20220627235401382

image-20220628000945313