Spring Cloud Sleuth、Zipkin可视化工具、以及服务链路追踪-61

一：Spring Cloud Sleuth

sleuth 英[sluːθ]/思路思

1.1 官方文档

https://cloud.spring.io/spring-cloud-static/spring-cloud-sleuth/2.1.3.RELEASE/single/spring-cloud-sleuth.html
https://docs.spring.io/spring-cloud-sleuth/docs/2.2.6.RELEASE/reference/html/

1.2 介绍

我们已经接触过几种微服务的监控方式，比如：Spring Boot Actuator监控微服务，Spring Boot Admin也是监控微服务，他是把Actuator的数据用可视化的方式呈现出来，Hystrix Dashboard监控Hystrix服务，Hystrix Turbine聚合多个Hystrix服务的监控信息等，接下来我们要讨论的是微服务的“跟踪"。
对于一个大型的几十个、几百个微服务构成的微服务架构系统，通常会遇到下面一些问题，比如：

• 如何串联整个调用链路，快速定位问题？
• 如何理清各个微服务之间的依赖关系？
• 如何进行各个微服务接口的性能分折？
• 如何跟踪整个业务流程的调用处理顺序？

Spring Cloud Sleuth为Spring Cloud提供了分布式跟踪的解决方案，它大量借用了Google Dapper、Twitter Zipkin和Apache HTrace的设计，帮我们解决像上面提到的问题。Spring Cloud Sleuth可以追踪10种类型的组件：async、Hystrix，messaging，WebSocket，rxjava，scheduling，Web（Spring MVC Controller，Servlet），WebClient（Spring RestTemplate）、Feign/OpenFegin、Zuul；

Spring Cloud Sleuth对于分布式链路的跟踪仅仅是生成一些数据，这些数据不便于人类阅读，所以我们一般把这种跟踪数据上传给Zipkin Server，由Zipkin通过UI页面统一进行数据的展示。

1.3 作用

• 可以方便的了解到每个采样的请求耗时，分析出哪些服务调用比较耗时。
• 对于程序未捕捉的异常，可以在集成Zipkin服务页面上看到。
• 识别调用比较频繁的服务，从而进行优化。

二：Zipkin

zipkin 英式读音：['zɪp kɪn]

2.1 官网

https://zipkin.io/

2.2 简介

Zipkin是Twitter开源的分布式实时数据跟踪系统（Distributed Tracking System），基于Google Dapper的论文设计而成，Google开源了 Dapper链路追踪组件，并在2010年发表了论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，这篇文章是业内实现链路追踪的标杆和理论基础，具有非常大的参考价值。

Zipkin它的主要功能是收集系统的时序数据，从而追踪微服务架构的系统延时等问题，从而达到链路调用监控跟踪作用，另外Zipkin还提供了一个非常友好的UI界面，来帮助分析追踪数据。除此之外，Zipkin提供了可插拔数据存储方式：In-Memory、MySql、Cassandra以及Elasticsearch。

2.3 Sleuth 和 Zipkin 异同

Sleuth 和 Zipkin 都是用来做分布式链路跟踪的，Zipkin 包含了 sleuth （指的 spring-cloud-starter-zipkin 包含 spring-cloud-starter-sleuth），Zipkin 分为服务端和客户端，服务端提供了一个 UI 监控界面，客户端指的每个服务

2.4 核心组件

• Collector：收集器组件，它主要用于处理从外部系统发送过来的跟踪信息，将这些信息转换为Zipkin内部处理的Span格式，以支持后续的存储、分析、展示等功能。
• Storage：存储组件，它主要对处理收集器接收到的跟踪信息，默认会将这些信息存储在内存中，我们也可以修改此存储策略，通过使用其他存储组件将跟踪信息存储到数据库中。
• RESTful API：API 组件，它主要用来提供外部访问接口。比如给客户端展示跟踪信息或是外接系统访问以实现监控等。
• Web UI：UI 组件，基于 API 组件实现的上层应用，通过 UI 组件用户可以方便而有直观地查询和分析跟踪信息。

Zipkin分为两端，一个是Zipkin服务端，一个是Zipkin客户端，客户端也就是微服务的应用。客户端会配置服务端的URL地址，一旦发生服务间的调用的时候，会被配置在微服务里面的Sleuth的监听器监听，并生成相应的Trace和Span信息发送给服务端。发送的方式主要有两种，一种是HTTP报文的方式，还有一种是消息总线的方式如：RabbitMQ。

最终我们可以总结出来，Sleuth和Zipkin的关系就好比Spring Boot Actuator和Spring Boot Admin之间的关系，一个用于产生数据，一个用于展示数据。

三：为什么使用Sleuth+Zipkin进行服务链路追踪

微服务架构是一个分布式架构，它按业务划分服务单元，一个分布式系统往往有很多个服务单元。由于服务单元数量众多，业务的复杂性，如果出现了错误和异常，很难去定位。主要体现在，一个请求可能需要调用很多个服务，而内部服务的调用复杂性，决定了问题难以定位。所以微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样的，从而达到每个请求的步骤清晰可见，出了问题，很快定位。
链路追踪组件有 Google 的 Dapper，Twitter 的 Zipkin，以及阿里的 Eagleeye （鹰眼）等，它们都是非常优秀的链路追踪开源组件。
简单说：假如服务 A -> B -> C -> D 调用顺序，如果 A 服务调用失败，排查失败原因时不能很快明确到底是哪个服务发生错误，使用分布式链路追踪可以很快明确哪个服务发生错误以及错误原因

四：基本术语

• Span（跨度）：基本工作单元，发送一个远程调度任务 就会产生一个 Span，Span 是一个 64 位 ID 唯一标识的，Trace 是用另一个 64 位 ID 唯一标识的，Span 还有其他数据信息，比如摘要、时间戳事件、Span 的 ID、以及进度 ID。
• Trace（跟踪）：一系列 Span 组成的一个树状结构。请求一个微服务系统的 API 接口，这个 API 接口，需要调用多个微服务，调用每个微服务都会产生一个新的 Span，所有由这个请求产生的 Span 组成了这个 Trace。
• Annotation（标注）：用来及时记录一个事件的，一些核心注解用来定义一个请求的开始和结束 。这些注解包括以下：
  1. cs - Client Sent -客户端发送一个请求，这个注解描述了这个 Span 的开始
  2. sr - Server Received -服务端获得请求并准备开始处理它，如果将其 sr 减去 cs 时间戳
     便可得到网络传输的时间。
  3. ss - Server Sent （服务端发送响应）–该注解表明请求处理的完成(当请求返回客户
     端)，如果 ss 的时间戳减去 sr 时间戳，就可以得到服务器请求的时间。
  4. cr - Client Received （客户端接收响应）-此时 Span 的结束，如果 cr 的时间戳减去
     cs 时间戳便可以得到整个请求所消耗的时间。

五：Springboot整合Sleuth

5.1 服务的提供者与消费者导入依赖

<dependency>
   <groupId>org.springframework.cloudgroupId>
   <artifactId>spring-cloud-starter-sleuthartifactId>
dependency>

5.2 开启debug日志

#开启debug日志
logging.level.org.springframework.cloud.openfeign=debug
logging.level.org.springframework.cloud.sleuth=debug

5.3 发起一次远程调用，观察控制台

DEBUG [user-service,541450f08573fff5,541450f08573fff5,false]

• user-service：服务名
• 541450f08573fff5：是 TranceId，一条链路中，只有一个 TranceId
• 541450f08573fff5：是 spanId，链路中的基本工作单元 id
• false：表示是否将数据输出到其他服务，true 则会把信息输出到其他可视化的服务上观察

六：整合 zipkin 可视化观察

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

6.1 docker安装zipkin服务器

docker安装zipkin服务器
docker run -d -p 9411:9411 openzipkin/zipkin

启动zipkin
doceker start angry_nightingale

6.2 导入zipkin依赖

<dependency>
	<groupId>org.springframework.cloudgroupId>
	<artifactId>spring-cloud-starter-zipkinartifactId>
dependency>

zipkin 依赖也同时包含了 sleuth，可以省略 sleuth 的引用

6.3 添加zipkin相关配置

为每一个微服务都加上服务追踪配置

#zipkin的访问地址
spring.zipkin.base-url=http://你服务器的ip:9411
#关闭自己的服务发现功能
spring.zipkin.discovery-client-enabled=false
#设置使用 http 的方式传输数据
spring.zipkin.sender.type=web
#配置sleuth的采样器
spring.sleuth.sampler.probability=1

6.4 Zipkin 数据持久化

1）Zipkin 数据持久化相关的官方文档地址如下：https://github.com/openzipkin/zipkin#storage-component
2）Zipkin 默认是将监控数据存储在内存的，如果 Zipkin 挂掉或重启的话，那么监控数据就会丢失。所以如果想要搭建生产可用的 Zipkin，就需要实现监控数据的持久化。而想要实现数据持久化，自然就是得将数据存储至数据库。好在 Zipkin 支持将数据存储至：

• 内存（默认）
• MySQL
• Elasticsearch
• Cassandra

3）Zipkin 支持的这几种存储方式中，内存显然是不适用于生产的，这一点开始也说了。而使用MySQL 的话，当数据量大时，查询较为缓慢，也不建议使用。Twitter 官方使用的是 Cassandra作为 Zipkin 的存储数据库，但国内大规模用 Cassandra 的公司较少，而且 Cassandra 相关文档也不多。

综上，故采用 Elasticsearch 是个比较好的选择，关于使用 Elasticsearch 作为 Zipkin 的存储数据库的官方文档如下：

1. elasticsearch-storage：https://github.com/openzipkin/zipkin/tree/master/zipkin-server#elasticsearch-storage
2. 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 支持的环境变量