springcloud入门系列（8）分布式服务跟踪sleuth＋

分布式服务跟踪需求

随着分布式服务越来越多，调用关系越来越复杂，组合接口越来越多，要进行分布式服务跟踪监控的需求也越来越强烈，对于项目负责人当生产环境出现问题的时候需要第一时间知道哪个服务节点出现了问题，这就需要我们能够通过监控系统第一时间发现。

分布式服务跟踪现状

目前主流的分布式服务跟踪开源框架主要有3个，大家用的比较多的是点评的CAT、pinpoint和sleuth＋zipkin，下面分别介绍下这几个框架的优缺点，之前我们公司内部也都使用过。

CAT：大众点评开源的内部服务跟踪框架，可以监控服务的关联关系，每个服务节点的耗时情况，数据库的耗时、网络的故障等等，监控的内容还是很全面的，但是需要注意的是CAT对代码存在一定的侵入性，需要对杯监控的方法增加注解才能完成服务监控；

pinpoint：是一个韩国人写的开源服务跟踪框架，pinpoint的好处就是对被监控的工程代码没有侵入性，只需要集成pinpoint的jar包就可以完成基本的服务性能监控了，上手非常简单；

sleuth＋zipkin：适合于公司使用springcloud框架的工程，集成起来更加方便，能和springcloud相关套件配合使用，能够监控到服务依赖关联、服务耗时等基本信息，也提供了丰富的查询功能，方便快速定位问题。

这3个开源框架，各有优缺点，CAT的优点是有更强的定制性，不仅仅局限在APM信息监控，还可以进行更多的功能拓展；pinpoint的优点就是容易上手，但是很难进行后续的功能扩展；sleuth的优点是在springcloud工程中集成非常简单，但也是后续很难进行功能扩展。

springcloud中的服务跟踪解决方案

springcloud作为主流的微服务框架中比较成熟的服务跟踪解决方案那就是sleuth＋zipkin，如果公司内部是实用springcloud作为基础搭建微服务的，建议直接使用sleuth和zipkin，sleuth作为服务跟踪框架，zipkin作为服务跟踪展示框架，能够方便的查看出每个服务节点的耗时情况，并能够将组合服务的调用关系链直观的展示出来，方便发现问题，并且对微服务工程的侵入性比较小。

sleuth＋zipkin原理

sleuth+zipkin的分布式服务跟踪方案和pinpoint一样都是根据google早年间发布的Dapper论文来实现的，这里简单描述下分布式服务跟踪的核心原理，要实现一个业务的全流程跟踪，那么每个全流程交易首先必须要有一个贯穿于全链路的TraceID用于标记出各个服务节点中哪些交易是归属于这笔业务交易的，但是我们筛选出了所有相关交易后还是无法知道每个服务节点之间的依赖关系和先后顺序关系，那么就还需要有一个表示这笔子交易的ID，因此在Dapper论文中又定义了一个SpanID，SpanID可以理解为在每个服务节点的最小工作单元，例如一个基本交易包含了请求和响应两个动作，那么就可以请求和响应各分配一个SpanID来唯一标示这个动作，请看下图，标示了3个串联调用的服务，每个服务都有一个请求动作和一个响应动作，在每个动作开始的时候都会分配一个唯一的SpanID，同时会将同一个TraceId一直传递下去。

Screenshot 2018-06-14 10.21.09

在每个服务节点都集成sleuth服务，sleuth服务会自动为每笔交易动作第一个服务节点生成一个全局唯一TraceId，这个TraceID会一直跟随交易传递下去，同时sleuth会为当前的动作再生成一个全局唯一的SpanId，在SpanId中可以体现出这个动作的上一个父动作的SpanId，同时也包含了动作发生时间信息，通过这些信息就能够还原出一棵交易的树形结构，通过对每个动作的开始、结束时间求差就能知道该笔交易每个动作之间的耗时。

上面介绍了sleuth的大概原理，下面再介绍下zipkin的原理，zipkin在整个服务跟踪里是用于接收sleuth为每个交易生成的TraceId和SpanId，zipkin对收集到的这些信息进行实时计算后进行一个树形结构的耗时展示，同时也提供了准实时查询功能，只需要通过简单的配置就能够满足基本的分布式服务跟踪需求。

微服务工程支持sleuth客户端

下面介绍下在sleuth客户端的开发工作，只需要进行POM的配置，工程引入对sleuth的两个依赖（最后两个），就可以自动监控分布式服务了，非常简单。

<dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-ribbon</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-sleuth</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-sleuth-zipkin</artifactId>
        </dependency>

    </dependencies>

下面这两条分别是两个服务在console里打出的日志信息，我们可以发现在日志头部多了几个信息。

[sleuth-testservice1,5856e53b441a241a,5856e53b441a241a,false] 1244 --- [nio-9091-exec-2] c.m.t.controller.TestController1         : ===call testController1===

[sleuth-testservice2,5856e53b441a241a,b1573c23f0322ab1,false] 1246 --- [nio-9092-exec-1] testservice.controller.TestController2   : ===call testController2===

• 第一个值：sleuth-testservice1，它记录了应用的名称，也就是application.yml中spring.application.name参数配置的属性。
• 第二个值：5856e53b441a241a，Spring Cloud Sleuth生成的一个ID，称为Trace ID，它用来标识一条请求链路。一条请求链路中包含一个Trace ID，多个Span ID。
• 第三个值：5856e53b441a241a，Spring Cloud Sleuth生成的另外一个ID，称为Span ID，它表示一个基本的工作单元，比如：发送一个HTTP请求。
• 第四个值：false，表示是否要将该信息输出到Zipkin等服务中来收集和展示，如果为true则表示该笔日志信息会传递到zipkin服务器进行统计，sleuth不是每笔交易都会上送zipkin，一般5笔交易会有一笔抽样上送zipkin，这么做是为了保证zipkin的性能。

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

同时为了将服务跟踪日志能发送到zipkin服务端进行统计，还需要在application.yml中配置zipkin的服务端地址。

server:
  port: 9092
spring:
  application:
    name: sleuth-testservice2
  zipkin:
    base-url: http://XX.XX.XX.XX:9411
eureka:
  client:
    serviceUrl:
      defaultZone: http://XX.XX.XX.XX:8761/eureka/

zipkin服务端

zipkin的服务端配置也非常简单，只需要两步配置。
首先在POM中引入zipkin的相关依赖，如下：

<dependencies>
        <dependency>
            <groupId>io.zipkin.java</groupId>
            <artifactId>zipkin-server</artifactId>
        </dependency>
        <dependency>
            <groupId>io.zipkin.java</groupId>
            <artifactId>zipkin-autoconfigure-ui</artifactId>
        </dependency>
    </dependencies>

再创建一个springboot的Applicatoin启动类，在启动类中加上 @EnableZipkinServer zipkin服务器注解，在需要被跟踪监控的sleuth客户端的配置文件中加上zipkin服务器地址的配置，上面也介绍过了。

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

打开http://XX.XX.XX.XX:9411/ 地址就可以查看到zipkin的console页面，在页面中输入需要查询的关键字和起止时间就可以进行查询了，这里需要注意因为sleuth并不是所有跟踪日志都会发送到zipkin，所以在zipkin查询到的只是一个采样统计。

Screenshot 2018-06-11 15.42.57

点开一个组合交易，可以看到这个组合交易由两个服务组成，图中也显示了节点耗时。

Screenshot 2018-06-11 15.43.15

点开后还可以看到每一个链路动作的明细信息。

Screenshot 2018-06-11 15.43.37

总结

这样就把在springcloud中通过sleuth、zipkin进行监控的过程从原理到实现进行了一个简单的介绍，总的来说还是比较简单的，原理也不是很复杂，感兴趣的同学还可以翻看下相关源码，sleuth的核心是唯一发号器和动态代理，zipkin的核心是交易的树形结构的生成和内存实时统计，本文涉及到的源码都加到了入门系列的工程中，感兴趣的可以下载下来看看，涉及到的模块有zipkin－server、sleuth-testservice1、sleuth-testservice2。

源码git：https://github.com/feiweiwei/springcloud-sample.git