源码地址: https://github.com/coderTomato/microservicecloud
1 Sleuth 简介
打开官网就可以看到对 Sleuth 的一个简单功能介绍。
(Spring Cloud Sleuth可以实现)针对Spring Cloud应用程序的分布式跟踪,兼容Zipkin、 HTrace 和基于日志的(如 Elk)跟踪。
Spring Cloud Sleuth 为 Spring Cloud 实现了一个分布式跟踪解决方案,大量借鉴了 Dapper、Zipkin 和 HTrace。对于大多数用户来说,Sleuth 是不可见的,并且你的当前应用与 外部系统的所有交互都是自动检测的。你可以简单地在日志中捕获数据,或者将其发送到远程收集器中。
2 Sleuth 基本理论
2.1 Spring Cloud Sleuth 文档
Spring Cloud Sleuth 的官方文档中可以查看到服务跟踪的基本理论。
2.2 三大概念
服务跟踪理论中存在有跟踪单元的概念,而跟踪单元中涉及三个重要概念:trace、span, 与 annotation。
(1) trace 与 span
- trace:跟踪单元是从客户端所发起的请求抵达被跟踪系统的边界开始,到被跟踪系统向客户返回响应为止的过程,这个过程称为一个 trace。
- span:每个 trace 中会调用若干个服务,为了记录调用了哪些服务,以及每次调用所消耗的时间等信息,在每次调用服务时,埋入一个调用记录,
这样两个调用记录之间的区域称为一个 span。 - 关系:一个Trace由若干个有序的Span组成。
Spring Cloud Sleuth 为服务之间调用提供链路追踪功能。为了唯一的标识 trace 与 span, 系统为每个 trace 与 span 都指定了一个 64 位长度的数字作为 ID,即 traceID 与 spanID。
(2) annotation
用于及时记录事件的实体,表示一个事件发生的时间点。这些实体本身仅仅是为了原理 叙述的方便,对于 Spring Cloud Sleuth 本身并没有什么必要性。这样的实体有多个,常用的有四个:
- cs:Client Send,表示客户端发送请求的时间点。
- sr,Server Receive,表示服务端接收到请求的时间点。
- ss:Server Send,表示服务端发送响应的时间点。
- cr:Client Receive,表示客户端接收到服务端响应的时间点。
2.3 Sleuth 的日志采样
(1) 日志生成
只要在工程中添加了 Spring Cloud Sleuth 依赖, 那么工程在启动与运行过程中就会自动 生成很多的日志。Sleuth 会为日志信息打上收集标记,需要收集的设置为 true,不需要的设 置为 false。这个标记可以通过在代码中添加自己的日志信息看到。
(2) 日志采样率
Sleuth 对于这些日志支持抽样收集,即并不是所有日志都会上传到日志收集服务器,日 志收集标记就起这个作用。默认的采样比例为: 0.1,即 10%。在配置文件中可以修改该值。 若设置为 1 则表示全部采集,即 100%。
Sleuth 默认采用的是水塘抽样算法。
3 "跟踪日志"的生产者 Sleuth
3.1 创建提供者工程 msc-sleuth-provider-8081
(1) 创建工程
复制 msc-provider-8081,并重命名为 msc-sleuth-provider-8081。
(2) 导入依赖
<!--sleuth依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
复制代码
(3) 修改处理器
3.2 创建消费者工程 msc-sleuth-consumer-8080
(1) 创建工程
复制 msc-consumer8080,并重命名为 msc-sleuth-consumer8080
(2) 导入依赖
<!--sleuth依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
复制代码
(3) 修改处理器
3.3 测试
先启动msc-eureka8761
再启动msc-sleuth-provider8081
最后启动msc-sleuth-consumer8080
访问
查看生成的日志
4 zipkin 工作过程
4.1 zipkin 简介
zipkin 是 Twitter 开发的一个分布式系统 APM(Application Performance Management,应 用程序性能管理)工具,其是基于 Google Dapper 实现的,用于完成日志的聚合。其与 Sleuth 联用,可以为用户提供调用链路监控可视化 UI 界面。
4.2 zipkin 系统结构
4.2.1 服务器组成
zipkin 服务器主要由 4 个核心组件构成:
- Collector:收集组件,它主要用于处理从外部系统发送过来的跟踪信息,将这些信息转换为 Zipkin 内部处理的 Span格式,以支持后续的存储、分析、展示等功能。
- Storage:存储组件,它主要用于处理收集器接收到的跟踪信息,默认会将这些信息存储在内存中,也可以修改存储策略,例如,将跟踪信息存储到数据库中。
- API:外部访问接口组件,外部系统通过这里的API可以实现对系统的监控。
- UI:用于操作界面组件,基于 API 组件实现的上层应用。通过 UI 组件用户可以方便而有直观地查询和分析跟踪信息。
4.2.2 日志发送方式
在 Spring Cloud Sleuth + Zipkin 系统中,客户端中一旦发生服务间的调用,就会被配置在 微服务中的 Sleuth 的监听器监听,然后生成相应的 Trace 和 Span 等日志信息,并发送给 Zipkin 服务端。发送的方式主要有两种,一种是通过 via HTTP 报文的方式,也可以通过 Kafka、 RabbitMQ 发送。
5 zipkin 服务端搭建
5.1 启动 zipkin 服务器
5.1.1 下载
在终端执行命令curl -sSL https://zipkin.io/quickstart.sh | bash -s
5.1.2 启动
java -jar zipkin.jar
5.2 访问 zipkin 服务器
6创建 zipkin 客户端工程-via
6.1 创建提供者 msc-via-sleuth-provider-8081
(1) 创建工程
复制 msc-sleuth-provider-8081,并重命名为 msc-via-sleuth-provider-8081
(2) 导入依赖
删除原来的 sleuth 依赖,导入 zipkin 依赖
打开 spring-cloud-starter-zipkin 依赖,可以看到其已经包含了 spring-cloud-starter-sleuth 依赖,所以可以将原来导入的 sleuth 依赖删除。
<!--zipkin客户端依赖,其包含了sleuth依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
复制代码
(3) 修改配置文件
在 spring 属性下注册 zipkin 服务器地址,并设置采样比例。
spring:
#指定zipkin服务器地址
zipkin:
base-url: http://localhost:9411/
#设置采样比例为1.0 即全部都需要,默认为0.1
sleuth:
sampler:
probability: 1.0
复制代码
6.2 创建消费者工程 msc-via-sleuth-consumer8080
(1) 创建工程
复制 msc-sleuth-consumer8080,并重命名为 msc-via-sleuth-consumer8080。
(2) 导入依赖
删除原来的 sleuth 依赖,导入 zipkin 依赖。
<!--zipkin客户端依赖,其包含了sleuth依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
复制代码
(3) 修改配置文件
在 spring 属性下注册 zipkin 服务器地址,并设置采样比例。
spring:
#指定zipkin服务器地址
zipkin:
base-url: http://localhost:9411/
#设置采样比例为1.0 即全部都需要,默认为0.1
sleuth:
sampler:
probability: 1.0
复制代码
(4) 启动工程
- msc-eureka8761
- msc-via-sleuth-provider8081
- msc-via-sleuth-consumer8080
- 访问 http://localhost:8080/consumer/depart/get/1
在zipkin里能看到刚才访问了两次
7 sleuth + kafka + zipkin
默认情况下,Sleuth 是通过将调用日志写入到 via 头部信息中的方式实现链路跟踪的, 但在高并发下,这种方式的效率会非常低,会影响链路信息查看的。此时,可以让 Sleuth 将其生成的调用日志写入到 Kafka 或 RabbitMQ 中,让 zipkin 从这些中间件中获取日志,效率会提高很多。
7.1 创建提供者工程
(1) 创建工程
复制 msc-sleuth-provider8081,并重命名为 msc-sleuth-provider-kafka8081
(2) 导入依赖
添加 kafka 依赖
<!--kafka依赖-->
<dependency>
<groupId>org.springframework.kafka</groupId>
<artifactId>spring-kafka</artifactId>
</dependency>
复制代码
(3) 修改配置文件
spring:
zipkin:
# 指定zipkin服务器的消息发送者是kafka
sender:
type: kafka
sleuth:
sampler:
probability: 1.0
# 指定当前Sleuth要连接的Kafka集群
kafka:
bootstrap-servers: node01:9092,node02:9092,node03:9092
复制代码
7.2 创建消费者工程
(1) 创建工程
复制 msc-sleuth-consumer8080,并重命名为 msc-sleuth-consumer-kafka8080
(2) 导入依赖
添加 kafka 依赖。
(3) 修改配置文件
spring:
zipkin:
# 指定zipkin服务器的消息发送者是kafka
sender:
type: kafka
sleuth:
sampler:
probability: 1.0
# 指定当前Sleuth要连接的Kafka集群
kafka:
bootstrap-servers: node01:9092,node02:9092,node03:9092
复制代码
7.3 启动运行
- 启动 zookeeper 集群
- 启动 kafka 集群
- zipkin 启动 在命令行启动 zipkin
java -DKAFKA_BOOTSTRAP_SERVERS=node01:9092 -jar zipkin.jar
复制代码
- 启动Eureka
- 启动提供者工程 msc-sleuth-provider-kafka8081
- 启动消费者工程 msc-sleuth-consumer-kafka8080
访问 http://localhost:8080/consumer/depart/get/1