手把手教你搭建SpringCloud项目（十八）集成Sleuth分布式链路跟踪

手把手教你搭建SpringCloud项目（十八）集成Sleuth分布式链路跟踪 Spring Cloud全文目录 源码 什么是微服务？有手就行 SpringCloud简介与5大常用组件 一、手把手教你搭建SpringCloud项目（一）搭建Maven父工程，傻瓜式 *** 作 二、手把手教你搭建SpringCloud项目（二）生产者与消费者 三、手把手教你搭建SpringCloud项目（三）集成Eureka服务注册中心 四、手把手教你搭建SpringCloud项目（四）EurekaServer集群版搭建 五、手把手教你搭建SpringCloud项目（五）生产者集群版搭建 六、手把手教你搭建SpringCloud项目（六）actuator微服务信息完善与Eureka自我保护机制 七、手把手教你搭建SpringCloud项目（七）Eureka实现服务发现(Discovery) 八、手把手教你搭建SpringCloud项目（八）集成Consul服务注册中心 九、手把手教你搭建SpringCloud项目（九）集成Ribbon负载均衡器 十、手把手教你搭建SpringCloud项目（十）集成OpenFeign服务接口调用 十一、手把手教你搭建SpringCloud项目（十一）集成Hystrix之服务降级 十二、手把手教你搭建SpringCloud项目（十二）集成Hystrix之服务熔断 十三、手把手教你搭建SpringCloud项目（十三）集成Hystrix之图形化Dashboard实时监控 十四、手把手教你搭建SpringCloud项目（十四）集成Gateway新一代服务网关 十五、手把手教你搭建SpringCloud项目（十五）集成Config分布式配置中心 十六、手把手教你搭建SpringCloud项目（十六）集成Bus消息总线 十七、手把手教你搭建SpringCloud项目（十七）集成Stream消息驱动 十八、手把手教你搭建SpringCloud项目（十八）集成Sleuth分布式链路跟踪

文章持续更新中，欢迎关注！

今天这篇文章介绍一下链路追踪相关的知识，以Spring Cloud Sleuth和zipkin这两个组件为主。

为什么需要链路追踪？

大型分布式微服务系统中，一个系统被拆分成N多个模块，这些模块负责不同的功能，组合成一套系统，最终可以提供丰富的功能。在这种分布式架构中，一次请求往往需要涉及到多个服务，如下图：

服务之间的调用错综复杂，对于维护的成本成倍增加，势必存在以下几个问题：

• 服务之间的依赖与被依赖的关系如何能够清晰的看到？
• 出现异常时如何能够快速定位到异常服务？
• 出现性能瓶颈时如何能够迅速定位哪个服务影响的？

为了能够在分布式架构中快速定位问题，分布式链路追踪应运而生。将一次分布式请求还原成调用链路，进行日志记录，性能监控并将一次分布式请求的调用情况集中展示。比如各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态等等。

常见的链路追踪技术有哪些？

市面上有很多链路追踪的项目，其中也不乏一些优秀的，如下：

• cat：由大众点评开源，基于Java开发的实时应用监控平台，包括实时应用监控，业务监控 。 集成方案是通过代码埋点的方式来实现监控，比如： 拦截器，过滤器等。 对代码的侵入性很大，集成成本较高，风险较大。

• zipkin：由Twitter公司开源，开放源代码分布式的跟踪系统，用于收集服务的定时数据，以解决微服务架构中的延迟问题，包括：数据的收集、存储、查找和展现。该产品结合spring-cloud-sleuth使用较为简单， 集成很方便， 但是功能较简单。

• pinpoint：韩国人开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能强大，接入端无代码侵入

• skywalking：SkyWalking是本土开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能较强，接入端无代码侵入。目前已加入Apache孵化器。

• Sleuth：Spring Cloud 提供的分布式系统中链路追踪解决方案。很可惜的是阿里系并没有链路追踪相关的开源项目，我们可以采用Spring Cloud Sleuth+Zipkin来做链路追踪的解决方案。

Spring Cloud Sleuth是什么？

Spring Cloud Sleuth实现了一种分布式的服务链路跟踪解决方案，通过使用Sleuth可以让我们快速定位某个服务的问题。简单来说，Sleuth相当于调用链监控工具的客户端，集成在各个微服务上，负责产生调用链监控数据。

Spring Cloud Sleuth就提供了一套完整的服务跟踪的解决方案，在分布式系统中提供了追踪解决方案并且兼容支持了zipkin，Spring Cloud Sleuth负责对微服务调用链路的收集整理，而zipkin负责对链路的展现。

学习Sleuth之前必须了解它的几个概念：

• Span：基本的工作单元，相当于链表中的一个节点，通过一个唯一ID标记它的开始、具体过程和结束。我们可以通过其中存储的开始和结束的时间戳来统计服务调用的耗时。除此之外还可以获取事件的名称、请求信息等。

• Trace：一系列的Span串联形成的一个树状结构，当请求到达系统的入口时就会创建一个唯一ID（traceId），唯一标识一条链路。这个traceId始终在服务之间传递，直到请求的返回，那么就可以使用这个traceId将整个请求串联起来，形成一条完整的链路。

• Annotation：一些核心注解用来标注微服务调用之间的事件，重要的几个注解如下：

  • cs（Client Send）：客户端发出请求，开始一个请求的生命周期
  • sr（Server Received）：服务端接受请求并处理；sr-cs = 网络延迟 = 服务调用的时间
  • ss（Server Send）：服务端处理完毕准备发送到客户端；ss - sr = 服务器上的请求处理时间
  • cr（Client Reveived）：客户端接受到服务端的响应，请求结束； cr - sr = 请求的总时间

什么是ZipKin？

Zipkin 是 Twitter 的一个开源项目，它基于Google Dapper实现，它致力于收集服务的定时数据，

以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。

ZipKin的基础架构如下图：

Zipkin共分为4个核心的组件，如下：

• Collector：收集器组件，它主要用于处理从外部系统发送过来的跟踪信息，将这些信息转换为Zipkin内部处理的 Span 格式，以支持后续的存储、分析、展示等功能。

• Storage：存储组件，它主要对处理收集器接收到的跟踪信息，默认会将这些信息存储在内存中，我们也可以修改此存储策略，通过使用其他存储组件将跟踪信息存储到数据库中

• RESTful API：API 组件，它主要用来提供外部访问接口。比如给客户端展示跟踪信息，或是外接系统访问以实现监控等。

• UI：基于API组件实现的上层应用。通过UI组件用户可以方便而有直观地查询和分析跟踪信息

zipkin分为服务端和客户端，服务端主要用来收集跟踪数据并且展示，客户端主要功能是发送给服务端，微服务的应用也就是客户端，这样一旦发生调用，就会触发监听器将sleuth日志数据传输给服务端。

zipkin服务端如何搭建？

Spring Cloud从F版之后就不需要自己构建Zipkin Server了，只需要调用相关jar包即可

首先需要下载服务端的jar包，地址：https://search.maven.org/artifact/io.zipkin/zipkin-server/2.23.4/jar

下载完成将会得到一个jar包，如下图：

直接启动这个jar，命令如下：

java -jar zipkin-server-2.23.4-exec.jar

出现以下界面表示启动完成：

此时可以访问zipkin的UI界面，地址：http://localhost:9411，界面如下：

以上是通过下载jar的方式搭建服务端，当然也有其他方式安装，比如docker，自己去尝试一下吧，我就不再演示了。

zipKin客户端如何搭建？

服务端只是跟踪数据的收集和展示，客户端才是生成和传输数据的一端，下面详细介绍一下如何搭建一个客户端。

在需要被链路监控的微服务中引入如下依赖：

      org.springframework.cloud
      spring-cloud-starter-zipkin

注意：由于spring-cloud-starter-zipkin中已经包含了Spring Cloud Sleuth依赖，因此只需要引入上述一个依赖即可。

比如在我们最开始学习Eureka服务注册中心时使用的8001微服务（服务提供方）和81微服务（服务消费方），那时候81微服务作为服务消费方访问8001提供的微服务，我们现在在这两个微服务中引入上述依赖，并在配置文件中配置zipkin和sleuth的配置信息：

spring:
  sleuth:
    sampler:
      # 采样率值介于0到1之间，1表示全部采集
      # 日志数据采样百分比，默认0.1(10%)，这里为了测试设置成了100%，生产环境只需要0.1即可
      probability: 1
  zipkin:
      #zipkin server的请求地址
    base-url: http://127.0.0.1:9411

在81和8001微服务都引入了上述依赖并添加了上面的配置后，启动Eureka服务注册中心、8001服务提供方服务、81服务消费方服务，然后我们用81调用8001的服务进行测试，访问http://localhost:81/consumer/payment/get/1，调用接口之后，再次访问zipkin的UI界面，即可查看服务调用链路：

可以看到刚才调用的接口已经被监控到了，点击SHOW进入详情查看，如下图：

可以看到左边展示了一条完整的链路，包括服务名称、耗时，右边展示服务调用的相关信息，包括开始、结束时间、请求url，请求方式…

除了调用链路的相关信息，还可以清楚看到每个服务的依赖，如下图：

zipKin的数据传输方式如何切换？

zipkin默认的传输方式是HTTP，但是这里存在一个问题，一旦传输过程中客户端和服务端断掉了，那么这条跟踪日志信息将会丢失。

当然zipkin还支持MQ方式的传输，支持消息中间件有如下几种：

• ActiveMQ
• RabbitMQ
• Kafka

使用MQ方式传输不仅能够保证消息丢失的问题，还能提高传输效率，生产中推荐MQ传输方式。

那么问题来了，如何切换呢？
其实方式很简单，下面以RabbitMQ为例介绍一下。

1、服务端连接RabbitMQ

运行服务端并且连接RabbitMQ，命令如下：

java -jar zipkin-server-2.23.4-exec.jar --zipkin.collector.rabbitmq.addresses=localhost --
zipkin.collector.rabbitmq.username=guest --zipkin.collector.rabbitmq.password=guest

命令分析如下：

• zipkin.collector.rabbitmq.addresses：MQ地址
• zipkin.collector.rabbitmq.username：用户名
• zipkin.collector.rabbitmq.password：密码

2、客户端添加RabbitMQ

既然使用MQ传输，肯定是要添加对应的依赖和配置了，添加RabbitMQ依赖如下：

  org.springframework.boot
  spring-boot-starter-amqp

配置MQ的地址、用户名、密码，配置如下：

spring:
  rabbitmq:
    addresses: 127.0.0.1
    username: guest
    password: guest

3、配置文件中传输方式切换

spring.zipkin.sender.type这个配置就是用来切换传输方式的，取值为rabbit则表示使用rabbitMQ进行数据传输。
配置如下：

spring:
  zipkin:
    sender:
     ## 使用rabbitMQ进行数据传输
      type: rabbit

注意：使用MQ传输，则spring.zipkin.base-url可以去掉。

完整的配置如下图：

4、测试

既然使用MQ传输，那么我们不启动服务端也是能够成功传输的，重启8001服务提供方服务、81服务消费方服务，浏览器访问：http://localhost:81/consumer/payment/get/1

此时发现服务并没有报异常，在看RabbitMQ中已经有数据传输过来了，存在zipkin这个队列中，如下图：

可以看到有消息未被消费，点进去可以看到消息内容就是Trace、Span相关信息。

好了，我们启动服务端，命令如下：

java -jar zipkin-server-2.23.4-exec.jar --zipkin.collector.rabbitmq.addresses=localhost --
zipkin.collector.rabbitmq.username=guest --zipkin.collector.rabbitmq.password=guest

服务端启动后发现zipkin队列中的消息瞬间被消费了，查看zipkin的UI界面发现已经生成了链路信息，如下图：

我们Spring Cloud Sleuth到这里就学习完毕了，那我们Spring Cloud整套也学习完了。是不是so easy！

下一系列我们开个专栏学习Spring Cloud Alibaba，持续学习，持续更新，下一节更精彩！欢迎朋友们点赞关注！感谢！