SpringCloud Sleuth + zipkin 实现微服务链路追踪功能

一、微服务架构下的问题

在大型的微服务架构系统中，存在很多不同的微服务应用，不同的微服务有依赖着其他微服务，以及不同微服务有可能由不同的团队维护。那么在这种复杂的系统架构中，将会存在一些问题，比如：

1. 如何快速发现问题（服务接口出现问题时，如何快速的确定是由哪一个调用节点出现问题）。
2. 如何判断一个服务出现问题后的影响范围。
3. 如何梳理服务依赖，以及依赖的合理性。
4. 如何分析链路性能，以及时容量规划（查看链路中哪一个调用过程耗时较长）。

分布式链路追踪（Disturbuted Tracing）,就是将一次调用还原成一个调用链路，进行日志记录。通过链路追踪的监控功能可以查看调用链上的服务具体落在那个节点上，每个节点上的处理耗时。

二、Sleuth + zipkin概述

SpringCloud Sleuth 主要功能就是在分布式系统中提供链路追踪解决方案。它大量的借用了Google Dapper的设计，并兼容支持了zipkin,只要引入相关依赖既可。Dapper中的专业术语：

Span: 基本工作单元，想当与微服务调用过程中的每一个最小的调用请求。每个调用环节都有不同的SpanId。但一次请求中的同一个调用链中traceId 相同。

Trace: 由一系列Span组成的一条数据链路。每一次请求中traceId 相同。

Zipkin 是 twitter 的一个开源项目。它基于 Google Dapper 实现。它致力于收集配置的节点上的定时数据。以解决微服务中的延迟问题，包括数据的收集、存储、查找和展现。使用zipkin可以收集链路上各个节点上的跟踪数据。通过其提供的REST API 接口 可以自定义实现我们的监控程序。或者使用其提供的UI界面直接查看链路调用信息。Zipkin提供了可插拔数据存储方式：内存存储、mysql,elasticsearch等。

Zipkin 分为 客户端和服务端

客户端：即微服务系统中的各个节点，客户端会配置服务端的url,一旦发生服务间的调用时，会被配置在微服务里面的sleuth监听器监听，并生成相应的 span 和 trace 信息发送给服务端。发送的方式主要有两种，一种http报文的形式，一种通过消息总线的形式如RabbitMQ。

服务端：服务端内部主要包含四部分 collector 收集器组件、Stotage 存储组件、Restful Api 组件、Web UI 组件。

三、链路追踪环境搭建

1，zipkin 服务端搭建

首先下载服务端启动jar包 zipkin-server-2.23.2-exec.jar。下载地址 https://zipkin.io/pages/quickstart.html

启动命令：

java -jar  zipkin-server-2.23.2-exec.jar 默认使用内存存储数据。

java -jar  zipkin-server-2.23.2-exec.jar --STORAGE_TYPE=mysql --MYSQL_HOST=127.0.0.1 --MYSQL_TCP_PORT=3306 --MYSQL_USER=root --MYSQL_PASS=11111 --MYSQL_DB=zipkin  使用数据库存储启动，需要提前准备好数据库环境表

java -jar zipkin-server-2.23.2-exec.jar --RABBIT_ADDRESSES=192.168.17.132:5672 使用rabbitMq 作为传输方式。

服务端访问地址：http://127.0.0.1:9411/zipkin/

2，zipkin 客户端搭建集成

我们首先准备四个工程，并保证请求通过网关能都正常访问到服务生产者工程，工程如下： 

1. cloud-payment-service ：服务生产者工程
2. cloud-order-service：服务消费者工程
3. eureka-server：服务注册中心
4. api-gateway-server：微服务网关工程

每个工程添加 sleuth + zipkin 依赖

<!-- 引入Sleuth 链路追踪依赖 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<!-- zipkin 日志手机 客户端依赖 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

配置文件配置其日志打印、sleuth采集比例 和 zipkin 服务端相关信息

spring
  zipkin:
    base-url: http://127.0.0.1:9411/ #zipkin 的服务端地址
    sender:
      type: web #采集日志向服务端传递的方式，还有mq等其他方式
  sleuth:
    sampler:
      probability: 1 # 采集日志比率 如 0.1

#添加日志级别可以控制台打印节点上的链路信息
logging:
  level:
    root: INFO
    org.springframework.web.servlet.DispatcherServlet: DEBUG
    org.springframework.cloud.sleuth: DEBUG

分别启动四个工程后，我们访问一次请求，在监控平台我们可以查到其调用的数据链路。

点击 show 按钮 我们可以查看其想起的调用信息

选择cloud-order-service 节点：

3，存在的问题及优化

使用http发送报文形式占用网络带宽，以及容易造成阻塞问题，下面我们将http形式 调整为使用RabbitMQ的方式，进行数据采集。

修改三个工程的 配置文件(修改zipkin.sender.type 为rabbit。添加spring.rabbitmq的配置)：

spring:
  zipkin:
    base-url: http://127.0.0.1:9411/ #zipkin 的服务端地址
    sender:
      type: rabbit #采集日志向服务端传递的方式，还有mq等其他方式
    sleuth:
      sampler:
        probability: 1 # 采集日志比率 如 0.1
  rabbitmq:
    host: 192.168.17.132
    port: 5672
    username: guest
    password: guest
    listener:
      direct:
        retry:
          enabled: true
      simple:
        retry:
          enabled: true
    

 

优化后：