springcloud — 微服务链路追踪sleuth组件

随着分布式服务架构的流行，特别是微服务等设计理念在系统中的应用，系统规模也会变得越来越大，各微服务间的调用关系也变得越来越复杂。通常一个由客户端发起的请求在后端系统中会经过多个不同的微服务调用来协同产生最后的请求结果。

在复杂的微服务架构系统中，几乎每一个前端请求都会形成一个复杂的分布式服务调用链路。那么就带来一系列问题，在业务规模不断增大、服务不断增多以及频繁变更的情况下，如何快速发现问题？如何判断故障影响范围？如何梳理服务依赖以及依赖的合理性？如何分析链路性能问题以及实时容量规划？面对上面这些问题，Spring Cloud Sleuth提供了分布式服务跟踪解决方案。

一、基本原理

如果想知道一个接口在哪个环节出现了问题，就必须清楚该接口调用了哪些服务，以及调用的顺序，如果把这些服务串起来，看起来就像链条一样，我们称其为调用链。

二、基本概念

spanid：每次调用服务的顺序。
traceid：每次请求的唯一标识。
parentid：标识调用服务的层级关系。
timestamp：上述的三个标识还不够，还需要加上时间戳，时间戳可以更精细一点，精确到微秒级。

虽然能计算出从服务调用到服务返回的总耗时，但是这个时间包含了服务的执行时间和网络延迟，有时候我们需要区分出这两类时间以方便做针对性优化。那如何计算网络延迟呢？我们可以把调用和返回的过程分为以下四个事件。

1. Client Sent简称cs，客户端发起调用请求到服务端。
2. Server Received简称sr，指服务端接收到了客户端的调用请求。
3. Server Sent简称ss，指服务端完成了处理，准备将信息返给客户端。
4. Client Received简称cr，指客户端接收到了服务端的返回信息。

假如在这四个事件发生时记录下时间戳，就可以轻松计算出耗时，比如sr减去cs就是调用时的网络延迟，ss减去sr就是服务执行时间，cr减去ss就是服务响应的延迟，cr减cs就是整个服务调用执行的时间。

整个请求的duration = cr - cs
服务端处理的耗时 = ss -sr
网络耗时 = （sr-cs）+ (cr-ss)

其实span块内除了记录这几个参数之外，还可以记录一些其他信息，比如发起调用服务名称、被调服务名称、返回结果、IP、调用服务的名称等，最后，我们再把相同spanid的信息合成一个大的span块，就完成了一个完整的调用链。

三、Sleuth + Zipkin 实现微服务跟踪

1、Zipkin

spring boot 2.x版本和之前发生了很大变化，Sleuth服务端不需要我们部署了，我们只需要从官网下载下来jar包就可以，启动起来就是服务端。

Zipkin主要收集分布式服务的时间数据，主要包括以下组件：

1. collector:数据采集；
2. storage:数据存储；
3. search:数据查询；
4. UI：数据展示
5. Zipkin提供可插拔数据存储方式：主要包括In-Memory，MySql，Cassandra或者Elasticsearch

这里说一下jar包下载下来要改名zipkin.jar，否则启动不起来。
java -jar zipkin.jar启动：

接着我们访问9411端口，可以看到zipkin的管理界面：

2、添加依赖和配置

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-sleuth-zipkin</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

添加配置：

spring.zipkin.base-url=http://localhost:9411
spring.zipkin.enabled=true

然后启动调用:会在消费者这端刷出大量的日志。

 INFO [demo,14071cd1d63f3520,e559bbd4e7057442,false] 

第一个值： demo, 它记录了应用的名称，也就是 application.properties中 spring.application.name参数配置的属性
第二个值： 14071cd1d63f3520, Spring Cloud Sleuth生成的一个ID,称为Trace ID,它用来标识一条请求链路。 一条请求链路中包含一个TraceID, 多个SpanID。
第三个值： e559bbd4e7057442, Spring Cloud Sleuth生成的另外一个 ID, 称为Span ID, 它表示一个基本的工作单元， 比如发送一个HTTP请求。
第四个值： false, 表示是否要将该信息输出到Zipkin等服务中来收集和展示。

上面四个值中的Trace ID和SpanID是Spring Cloud Sleuth实现分布式服务跟踪的核心。 在一次服务请求链路的调用过程中， 会保待并传递同一个Trace ID, 从而将整个分布于不同微服务进程中的请求跟踪 信息串联起来。

在使用RestTemplate请求，sleuth 组件会对该请求进行处理。在发送到其他服务之前， Sleuth会 在该请求的Header中增加实现 跟踪需要的重要信息，主要有下面这几个（更多关于头信息的定义可以通过查看 org.springframework.cloud.sleuth.Span的源码获取）。

• X-B3-Traceld: 一条请求链路 (Trace) 的唯一标识， 必需的值。

• X-B3-Spanld: 一个工作单元 (Span) 的唯一标识， 必需的值。

• X-B3-ParentSpanld: 标识当前工作单元所属的上一个工作单元 ， Root Span(请求链路的第一个工作单元)的该值为空。

• X-B3-Sampled: 是否被抽样输出的标志， 1 表示需要被输出 ， 0 表示不需要被输出 。

• X-Span-Name: 工作单元的名称。

这些参数都是可以在请求头中取到的。