Spring Cloud系列之链路追踪

Spring Cloud系列之Eureka
Spring Cloud系列之配置中心Config
Spring Cloud系列之gateway
Spring Cloud系列之Feign
Spring Cloud系列之Hystrix
Spring Cloud系列之链路追踪

场景描述

在微服务架构下，一次请求至少经过三四次服务调用完成，多则跨越七八个，那么问题接踵而来

如何动态展示服务的调用链路
如何分析服务调用链路中的节点，耗时多少，并进行调优
如何发现其中某次调用故障

基于上面得问题，就应运而生了分布式调用链路追踪技术

常用的分布式链路追踪方案

spring cloud sleuth+twitter zipkin
阿里巴巴的鹰眼
大众点评的 CAT
美团的 Mtrace
京东的hydra
新浪的watchman
apache skywalking

分布式链路实现思想

本质：记录日志，进行分析、排障

一次请求我们可以想象成一棵树，如下图：

trace_tree.png

Trace调用模型，主要有以下概念：

Trace：一次完整的分布式调用跟踪链路,由一系列Span 组成的一个树状结构

TraceId：为了实现请求跟踪，当请求发送到分布式系统的入口时，我们为该请求创建一个唯一跟踪表示traceId,同时在分布式系统内部流转时，框架始终保持该唯一标识。

Span（跨度）：追踪服务调基本结构，表示跨服务的一次调用；多span形成树形结构，组合成一次Trace追踪记录。对于一个span节点必须有开始和结束节点，通过记录开始和结束的时间戳，就可以计算出调用该服务的一个耗时。每一个Span通过一个64位ID来进行唯一标识即spanId，并通过另一个64位ID对Span所在的Trace进行唯一标识。（注意：启动一个Trace的初始化Span被叫作 Root Span ，它的 Span ID 和 Trace Id 相同。）

span除了时间戳外，还可以包含一些其他元素数据，比如请求信息 parentId、traceId、spanId。

Annotation：用来及时记录一个事件的存在。通过引入 Brave 库，我们不用再去设置一系列的特别事件，从而让 Zipkin 能够知道客户端和服务器是谁、请求是从哪里开始的、又到哪里结束。出于学习的目的，还是把这些事件在这里列举一下：

Cs CLIENT_SEND，客户端发起请求

Cr CLIENT_RECIEVE，客户端收到响应

Sr SERVER_RECIEVE，服务端收到请求

Ss SERVER_SEND，服务端发送结果

下面我们就重点来了解下sleuth+zipkin

Spring Cloud Sleuth+twitter zipkin

实现思想

追踪服务框架，Sleuth就是通过记录日志的方式来追踪数据的，我们可以通过记录的日志，进行：

耗时分析：通过sleuth了解采样请求的耗时，分析服务的性能问题
链路优化：发现频繁调用的服务，针对性的进行优化

我们往往把spring cloud sleuth和zipkin一起使用，把sleuth的数据信息发送给zipkin进行聚合，利用zipkin存储进行数据展示，具体实现流程如下：

sleuth_zipkin.png

sleuth项目搭建

引入依赖


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

配置文件

在application.yml中添加日志级别

#分布式链路追踪
logging:
  level:
    org.springframework.web.servlet.DispatcherServlet: debug
    org.springframework.cloud.sleuth: debug

运行项目，发起请求，我们可以看到user-api打印结果：

sleuth_log.png

但是这样看这个打印日志，首先不直观，而且也不好做分析，所以我们就需要引入zipkin

zipkin server项目搭建

引入依赖



    
        dy-springcloud
        com.dy
        0.0.1-SNAPSHOT
    
    4.0.0

    com.dy
    zipkin-server

    

        
        
            io.zipkin.java
            zipkin-server
            2.12.3
        

        
        
            io.zipkin.java
            zipkin-autoconfigure-ui
            2.12.3

配置文件
```
application.yml配置文件如下：
```

server:
  port: 10005
spring:
  application:
    name: zipkin-server
management:
  metrics:
    web:
      server:
        auto-time-requests: false  #关闭自动检测

启动类

package com.dy.zipkin;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import zipkin2.server.internal.EnableZipkinServer;

/**
 * @Description:
 * @author: dy
 */
@EnableZipkinServer  //开起zipkinServer服务器功能
@SpringBootApplication
public class ZipkinServerApplication {

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

}

运行项目，打开地址http://localhost:10005/zipkin/，界面如下：

zipkin-server-ui.png

zipkin client项目搭建

引入依赖

 

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

配置文件

server:
  port: 11001
spring:
  application:
    name: user-service
  zipkin:
    # zipkin server的请求地址
    base-url: http://localhost:10005/
    sender:
    #同步数据的方式
      type: web  
  sleuth:
    sampler:
      probability: 1 # 采样率 1代表百分之百 就是全部采集，默认是0.1 即百分之十

其中type方式有三种

web 客户端将踪迹日志数据通过网络请求http的方式发送到服务端
rabbit 客户端将踪迹日志数据通过mp rabbit的方式发送到服务端
kafka 客户端将踪迹日志数据通过mp kafka的方式发送到服务端

还有采样率的问题

生产环境下，如果采用全部采集，那产生的踪迹数据量就是一个天量，对于网络和server端的压力就非常大了，而且没必要采集所有的数踪迹数据进行分析，我们只需要采集一部分进行分析就可以了，这里我们本地方便查看就设置为1，线上我们可以根据我们自己的需求，综合考量，设置一个合适的采样率

运行项目，访问接口，我们可以看到如下页面：

sleuth请求链路.png

注意：spans的个数是按照入口和出口进行计算的比如第一条请求，请求入gateway算一个，gateway向user-api发起请求算一个，入user-api算一个，以此类推，第一个请求就有5个span

具体请求链路详情我们可以点击一个进入：

链路详情.png

zipkin 数据持久化

在这里我们简单介绍下，如果我们不持久化数据，数据是保存到内存中的，一旦服务重启，数据就丢失了，而且数据保存到内存中也存在很大的问题，一般我们持久化链路踪迹数据，Zipkin支持将追踪数据持久化到mysql或者es中，一般我们用的比较多的是es。

Spring Cloud系列之Eureka
Spring Cloud系列之配置中心Config
Spring Cloud系列之gateway
Spring Cloud系列之Feign
Spring Cloud系列之链路追踪