1、Sleuth(全链路追踪)
1.1、概要
Spring Cloud Sleuth提供了一套完整的服务跟踪的解决方案,并且支持集成了zipkin。
1.2、术语
1.2.1、Trace:
它是由一组有相同Trace ID的Span串联形成一个树状结构。为了实现请求跟踪,当请求到分布式系统的入口端点时,只需要服务跟踪框架为该请求创建一个唯一的跟踪标识(即前文提到的Trace ID),同时在分布式系统内部流转的时候,框架始终保持该传递的唯一标识,直到返回请求为止,我们通过它将所有请求过程中的日志关联起来;
1.2.2、Span:
它代表了一个基础的工作单元,例如服务调用。为了统计各处理单元的时间延迟,当前请求到达各个服务组件时,也通过一个唯一标识(即前文提到的Span ID)来标记它的开始、具体过程以及结束。通过span的开始和结束的时间戳,就能统计该span的时间延迟,除此之外,我们还可以获取如事件名称、请求信息等元数据。
1.2.3、Annotation:
它用于记录一段时间内的事件。
内部使用的最重要的注释是:
- cs - Client Sent - 客户端发送一个请求,这个注解描述了这个Span的开始。
- sr - Server Received - 服务端获得请求并准备开始处理它,其中(sr – cs) 时间戳便可得到网络传输的时间。
- ss - Server Sent (服务端发送响应)– 该注解表明请求处理的完成(当请求返回客户端), (ss – sr)时间戳就可以得到服务器请求的时间。
- cr - Client Received (客户端接收响应)- 表明此时Span的结束,(cr – cs)时间戳便可以得到整个请求所消耗的时间。
1.3、追踪原理
为了实现请求跟踪,当请求发送到分布式系统的入口端点时,只需要服务跟踪框架为该请求创建一个唯一的跟踪标识,同时在分布式系统内部流转的时候,框架始终保持传递该唯一标识,直到返回给请求方为止,这个唯一标识就是前文中提到的Trace ID。通过Trace ID的记录,我们就能将所有请求过程日志关联起来。
为了统计各处理单元的时间延迟,当请求达到各个服务组件时,或是处理逻辑到达某个状态时,也通过一个唯一标识来标记它的开始、具体过程以及结束,该标识就是我们前文中提到的Span ID,对于每个Span来说,它必须有开始和结束两个节点,通过记录开始Span和结束Span的时间戳,就能统计出该Span的时间延迟,除了时间戳记录之外,它还可以包含一些其他元数据,比如:事件名称、请求信息等。
表示一条请求链路,一条链路通过TraceId作为唯一标识,Span标识发起的请求信息也具有唯一标识,叫做SpanId,各span通过parentId关联起来(后一个Span的parentId就是前一个Span的SpanId)。
2、spring-cloud-sleuth整合zipkin
2.1、docker 安裝服务
docker run -d -p 9411:9411 openzipkin/zipkin
2.2、代码实现
pom
<!--链路追踪-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
<version>2.1.0.RELEASE</version>
</dependency>
yml
spring:
application:
name: gulimall-secondkill
zipkin:
base-url: http://192.168.56.10:9411
sender:
type: web
# 取消nacos对zipkin的服务发现
discovery-client-enabled: false
#采样取值介于 0到1之间,1则表示全部收集
sleuth:
sampler:
probability: 1
2.3、查询调用链路
可视化页面的地址:http://192.168.56.10:9411/zipkin
2.4、持久化es
Zipkin 默认是将监控数据存储在内存的,如果 Zipkin 挂掉或重启的话,那么监控数据就会丢 失。所以如果想要搭建生产可用的 Zipkin,就需要实现监控数据的持久化。而想要实现数据 持久化,自然就是得将数据存储至数据库。好在 Zipkin 支持将数据存储至:
- 内存(默认)
- MySQL
- Elasticsearch
- Cassandra
Zipkin 支持的这几种存储方式中,内存显然是不适用于生产的,这一点开始也说了。而使用 MySQL 的话,当数据量大时,查询较为缓慢,也不建议使用。Twitter 官方使用的是 Cassandra 作为 Zipkin 的存储数据库,但国内大规模用 Cassandra 的公司较少,而且 Cassandra 相关文 档也不多。 综上,故采用 Elasticsearch 是个比较好的选择,关于使用 Elasticsearch 作为 Zipkin 的存储数 据库的官方文档如下:
elasticsearch-storage: https://github.com/openzipkin/zipkin/tree/master/zipkin-server#elasticsearch-storage
zipkin-storage/elasticsearch https://github.com/openzipkin/zipkin/tree/master/zipkin-storage/elasticsearch
通过 docker 的方式启动
docker run --env STORAGE_TYPE=elasticsearch --env ES_HOSTS=192.168.56.10:9200 openzipkin/zipkin-dependencies
使用 es 时 Zipkin Dependencies 支持的环境变量