链路追踪Sleuth入门

前言：

在一个大型的分布式项目中存在各种各样的模块调用。每个模块负责不同的功能，组合成系统。

在这种架构下的系统，一次请求往往会调用到许许多多的微服务。这样的跨度对于维护也是存在一定的问题。

     1.如何快速发现问题？
     2.如何判断故障影响范围？
     3.如何梳理服务依赖以及依赖的合理性？
     4.如何分析链路性能问题以及实时容量规划？

 

对于这些问题我们可以采用分布式链路追踪进行解决。

 

分布式链路追踪（Distributed Tracing），就是将一次分布式请求还原成调用链路，进行日志记录，性能监控并将 一次分布式请求的调用情况集中展示。
比如各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态等等。

  目前业界比较流行的链路追踪系统如：Twitter的Zipkin，阿里的鹰眼，美团的Mtrace，大众点评的cat等，大部分都是基于google发表的Dapper。Dapper阐述了分布式系统，

  特别是微服务架构中链路追踪的概念、数据表示、埋点、传递、收集、存储与展示等技术细节。

 

对于链路追踪Spring也提供了其对应的方法：Spring Cloud Sleuth

Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 zipkin，只需要在pom文件中引入相应的依赖即可。

 

 

流程图：

 

 

链路追踪Sleuth入门 

（1）在需要的微服务下添加配置依赖

    <!--Sleuth链路追踪依赖-->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-sleuth</artifactId>
    </dependency>

（2）修改配置文件

修改application.yml添加日志级别 

logging:
  level:
    root: INFO
    org.springframework.web.servlet.DispatcherServlet: DEBUG
    org.springframework.cloud.sleuth: DEBUG  #链路追踪日志

（3）查看效果

http://localhost:8001/admin/category/demo.do/1

访问category微服务的demo.do服务。该服务会去远程调用demo微服务的demo.do服务。

 

 访问成功后我们可以观察微服务的控制台日志：

Category微服务控制台：

 Demo微服务控制台：

 

 调用之后，我们可以在控制台观察到sleuth的日志输出。

其中 蓝色框中的是TraceId，后面跟着的绿色框中的是SpanId，依次调用有一个全局的TraceId，将调用链

路串起来。仔细分析每个微服务的日志，不难看出请求的具体过程。

 

查看日志文件并不是一个很好的方法，当微服务越来越多日志文件也会越来越多，通过Zipkin可以将日

志聚合，并进行可视化展示和全文检索。

 

 关于基于 Zipkin的链路追踪可以查看下一章：

基于 Zipkin的链路追踪