Spring Cloud Sleuth

Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 zipkin，你只需要在pom文件中引入相应的依赖即可。
微服务架构上通过业务来划分服务的，通过REST调用，对外暴露的一个接口，可能需要很多个服务协同才能完成这个接口功能，如果链路上任何一个服务出现问题或者网络超时，都会形成导致接口调用失败。
随着业务的不断扩张，服务之间互相调用会越来越复杂。

Spring Cloud Sleuth的专业术语：

Span：基本工作单元，例如，在一个新建的span中发送一个RPC等同于发送一个回应请求给RPC，span通过一个64位ID唯一标识，trace以另一个64位ID表示，span还有其他数据信息，比如摘要、时间戳事件、关键值注释(tags)、span的ID、以及进度ID(通常是IP地址) span在不断的启动和停止，同时记录了时间信息，当你创建了一个span，你必须在未来的某个时刻停止它。
Trace：一系列spans组成的一个树状结构，例如，如果你正在跑一个分布式大数据工程，你可能需要创建一个trace。
Annotation：用来及时记录一个事件的存在，一些核心annotations用来定义一个请求的开始和结束
cs ：Client Sent -客户端发起一个请求，这个annotion描述了这个span的开始
sr ： Server Received -服务端获得请求并准备开始处理它，如果将其sr减去cs时间戳便可得到网络延迟
ss ：Server Sent -注解表明请求处理的完成(当请求返回客户端)，如果ss减去sr时间戳便可得到服务端需要的处理请求时间
cr ：Client Received -表明span的结束，客户端成功接收到服务端的回复，如果cr减去cs时间戳便可得到客户端从服务端获取回复的所有所需时间

将Span和Trace在一个系统中使用Zipkin注解的过程图形化：

Span和Trace图形化

Spring Cloud Zipkin

Spring cloud提供了spring-cloud-sleuth-zipkin来方便集成zipkin实现，Zipkin是Twitter的一个开源项目，它基于Google Dapper实现。
我们可以使用它来收集各个服务器上请求链路的跟踪数据，并通过它提供的REST API接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序，从而及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源。
除了面向开发的API接口之外，它也提供了方便的UI组件来帮助我们直观的搜索跟踪信息和分析请求链路明细。

zipkin-architecture

上图展示了Zipkin的基础架构，它主要有4个核心组件构成：

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

新建一个基础Spring的Maven Moudle工程命名为zipkin，引用所需的依赖：

    
        com.wkedong.springcloud
        parent
        0.0.1-SNAPSHOT
    

    
        
            io.zipkin.java
            zipkin-server
        
        
            io.zipkin.java
            zipkin-autoconfigure-ui
        
        
            io.zipkin.java
            zipkin-autoconfigure-storage-mysql
        
        
            mysql
            mysql-connector-java
        
        
            org.springframework.boot
            spring-boot-starter-data-jpa
        
    

    
        
            
                org.springframework.boot
                spring-boot-maven-plugin

这里依赖了zipkin相关的服务和Mysql数据库（zipkin数据存入数据库进行持久化保存）

注：需要支持zipkin追踪的应用需要在pom文件里依赖以下内容,这里不一一赘述


  org.springframework.cloud
  spring-cloud-sleuth-zipkin


  org.springframework.cloud
  spring-cloud-starter-sleuth

application.yml配置文件如下：

server:
  port: 6040
spring:
  application:
    name: zipkin
  datasource:
    url: jdbc:mysql://127.0.0.1:3306/spring_cloud_zipkin?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8
    username: root
    password: 123456
    driver-class-name: com.mysql.jdbc.Driver

接下来我们修改应用主类：


/**
 * @author wkedong
 */
@EnableZipkinServer
@SpringBootApplication
public class ZipkinApplication {

    public static void main(String[] args) {
        SpringApplication.run(ZipkinApplication.class, args);
    }

}

@EnableZipkinServer注解表示该应用为zipkin服务

启动该应用并访问http://localhost:6040 ，出现zipkin查看的UI图形页面：

Zipkin

启动Eureka，Config，ServiceProducer，ServiceConsumer并访问Consumer接口/testGet接口，观察控制台输出

Consumer下输出:

2019-02-16 09:45:35.717  INFO [service-consumer,b97e2da610e3a31a,b97e2da610e3a31a,true] 16052 --- [nio-7010-exec-1] c.w.s.s.controller.ConsumerController    : ======

Producer下输出:

2019-02-16 09:45:36.177  INFO [service-producer,b97e2da610e3a31a,0f79122e2926c368,true] 14500 --- [nio-6070-exec-1] c.w.s.s.controller.ProducerController    : ======
2019-02-16 09:45:36.177  INFO [service-producer,b97e2da610e3a31a,0f79122e2926c368,true] 14500 --- [nio-6070-exec-1] c.w.s.s.s.impl.ProducerServiceImpl       : /testGet, instanceId:HANWEB-PC:service-producer:6070, host:HANWEB-PC

从上面的控制台输出内容中，我们可以看到多了一些形如[service-consumer,b97e2da610e3a31a,b97e2da610e3a31a,true]的日志信息，而这些元素正是实现分布式服务跟踪的重要组成部分，它们每个值的含义如下：

第一个值：service-consumer，它记录了应用的名称，也就是application.properties中spring.application.name参数配置的属性。
第二个值：b97e2da610e3a31a，Spring Cloud Sleuth生成的一个ID，称为Trace ID，它用来标识一条请求链路。一条请求链路中包含一个Trace ID，多个Span ID。
第三个值：b97e2da610e3a31a，Spring Cloud Sleuth生成的另外一个ID，称为Span ID，它表示一个基本的工作单元，比如：发送一个HTTP请求。
第四个值：true，表示是否要将该信息输出到Zipkin等服务中来收集和展示。（这里有些人可能是false，因为在各个应用配置文件中sleuth:sampler:percentage: #zipkin收集率为配置，未配置的默认值为0.1即10%的收集率，改为1即可100%收集）

上面四个值中的Trace ID和Span ID是Spring Cloud Sleuth实现分布式服务跟踪的核心。
在一次服务请求链路的调用过程中，会保持并传递同一个Trace ID，从而将整个分布于不同微服务进程中的请求跟踪信息串联起来，以上面输出内容为例，service-consumer和service-producer同属于一个前端服务请求来源，所以他们的Trace ID是相同的，处于同一条请求链路中。

现在查看zipkin管理页面:

Zipkin管理页面
可以看到多了一个访问Traces记录，点击进去:

Traces

得到Sleuth收集到的跟踪到详细信息，其中包括了请求服务名，请求接口，请求时间消耗等。

点击依赖分析:

依赖分析

查看Zipkin Server根据跟踪信息分析生成的系统请求链路依赖关系图

文章目录：

Spring Cloud（一）服务注册与发现

Spring Cloud（二）配置中心

Spring Cloud（三）服务消费

Spring Cloud（四）服务容错保护

Spring Cloud（五）服务网关

Spring-Cloud（六）服务追踪

整体demo的GitHub地址：Spring-Cloud

Spring-Cloud（六）服务追踪

Spring Cloud Sleuth