Spring cloud分布式链路跟踪：Sleuth Zipkin

背景

随着互联网的成长，需要支持大量的并发连接，并且需要将功能和服务有机结合，导致更加复杂的软件栈组合。更确切地说，多层架构（ SOA或者微服务架构）变得更加普遍。

• 那么问题来了：出了问题怎么排查？
  

解决方案-分布式链路追踪系统

• 提供链路追踪，故障快速定位：可以通过调用链结合业务日志快速定位错误信息。

• 可视化： 各个阶段耗时，进行性能分析。

• 依赖优化：各个调用环节的可用性、梳理服务依赖关系以及优化。

三大组件

分布式链路追踪系统 三大组件

• 跟踪组件 – 负责收集性能数据

• 收集与存储组件 – 负责将跟踪组件的数据

• 展示组件 – 将跟踪数据展示出来

跟踪组件

• 要解决的问题

• 最初的调用方是谁？

• 请求在每个结点执行了多久，这个结点的调用方是谁？

• 怎么把这些统计信息联系起来？

理论

Google 的论文 ： Dapper

• 分布式系统跟踪工具的设计空间已经被一些优秀文章探索过了，其中的Pinpoint[9]、Magpie[3]和X-Trace[12]和Dapper最为相近。这些系统在其发展过程的早期倾向于写入研究报告中，即便他们还没来得及清楚地评估系统当中一些设计的重要性。

• 虽然Dapper在许多高阶的设计思想上吸取了Pinpoint和Magpie的研究成果，但在分布式跟踪这个领域中，Dapper的实现包含了许多新的贡献

• Trace Tree : 一次跟踪
• 树节点是Span，包括：
  • Span ID
  • 开始时间和结束时间
  • RPC时间数据
• 应用自定义标识数据annotations
• 树节点之间的边是Span 和它的父节点之间的关系
• 没有父节点的Span是根Span (root span)
• 所有树节点都有共同的一个Trace ID 标识这次跟踪

调用链实现步骤：

• 当一个线程处理一条跟踪的路径时Dapper把Trace context (Trace信息，包括Trace ID和- Span ID)放到ThreadLocal里面
• 如果计算要放到线程池里面进行，Dapper会注册一个callback，callback存储调用者的Trace context来达到继续跟踪的目的
• 对所有的RPC请求都加上Trace context

是不是有点复杂？

做个类比就一目了然了。 将这些东西和一棵树的元素对比下

TraceId-- RootId（根节点）

SpanId – NodeId （子节点）

Parent SpanId – parent NodeId （父节点描述信息）

其实本质就是为了生成一棵调用树。

追踪实现的方式有哪些？

• 硬编码？ Long time = end-start ; ?

• Spring aop ?

大致分为两种

interceptor

借助于组件自带的interceptor 功能。 就像 spring mvc 的 interceptor 一样

比如 httpclient ，mysql 驱动自带的拦截器功能。在开始之前记录时间，在执行完之后记录结束时间。

使用 agent 技术，比如Java agent

使用 java的 Instrumentation，开发者可以构建一个独立于应用程序的代理程序（Agent），用来监测和协助运行在 JVM 上的程序，甚至能够替换和修改某些类的定义。

有了这样的功能，开发者就可以实现更为灵活的运行时虚拟机监控和 Java 类操作了，这样的特性实际上提供了一种虚拟机级别支持的 AOP 实现方式，使得开发者无需对现有代码或者 JDK 做任何升级和改动，就可以实现某些 AOP 的功能了

在JDK5开始，在启动JVM时可增加-javaagent参数，在装载Class时对类进行动态的修改。

Java agent 在链路追踪上的应用

以httpClient为例：

java agent在jvm把相关类的字节流加载到内存之后，修改这些方法的具体实现（通常是在请求发送之前，开启一个spanEvent，记录发出请求的时间，在发送请求的时候，额外传入参数，向服务方发送transactionId 和 自己的spanId（通常是包含在http header 中）。 在请求结束的时候，记录结束的时间，算出耗时）

完整的链路追踪，需要调用端和服务端同时支持

以刚才讲的httpclient为例，服务端在接收到请求的时候，要检查是不是特殊的被追踪的请求（检查http header）。

如果是一个已经开始了的追踪请求，就以传入的traceId为准。否则就自己新起一个追踪。（类似于spring 事务传播机制中的required）

Sleuth简介

Sleuth是Spring Cloud的组件之一，它为Spring Cloud实现了一种分布式追踪解决方案，兼容Zipkin，HTrace和其他基于日志的追踪系统，例如 ELK（Elasticsearch 、Logstash、 Kibana）。

Sleuth相关术语

Sleuth引入了许多 Dapper中的术语：

• Span 基本的工作单元。无论是发送一个RPC或是向RPC发送一个响应都是一个Span。每一个Span通过一个64位ID来进行唯一标识，并通过另一个64位ID对Span所在的Trace进行唯一标识。
  Span能够启动和停止，他们不断地追踪自身的时间信息，当你创建了一个Span，你必须在未来的某个时刻停止它。
  提示：启动一个Trace的初始化Span被叫作 Root Span ，它的 Span ID 和 Trace Id 相同。

• Trace 由一系列Span 组成的一个树状结构。例如，如果你要执行一个分布式大数据的存储操作，这个Trace也许会由你的PUT请求来形成。

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

• cs （Client Sent） - 客户端发起一个请求，这个注释指示了一个Span的开始。

• sr （Server Received） - 服务端接收请求并开始处理它，如果用 sr 时间戳减去 cs 时间戳便能看出有多少网络延迟。

• ss（Server Sent）- 注释请求处理完成(响应已发送给客户端)，如果用 ss 时间戳减去sr 时间戳便可得出服务端处理请求耗费的时间。

• cr（Client Received）- 预示了一个 Span的结束，客户端成功地接收到了服务端的响应，如果用 cr 时间戳减去 cs 时间戳便可得出客户端从服务端获得响应所需耗费的整个时间。

下图展示了一个系统中的 Span 和 Trace 大概的样子：

使用Sleuth

为了确保你的应用名称能够在Zipkin中正确显示，你需要先在Springboot的核心配置文件中对spring.application.name 属性进行配置。

引入依赖

<dependencies>
		
		<dependency>
			<groupId>org.springframework.cloudgroupId>
			<artifactId>spring-cloud-starter-zipkinartifactId>
		dependency>
	dependencies>

sleuth与zipkin通信默认为HTTP, 指定Zipkin服务地址

spring.zipkin.base-url=http://192.168.1.20:9411

如果你想使用RabbitMQ 或者Kafka 替代 HTTP ，需先引入 spring-rabbit 或者 spring-kafka 依赖。默认的目标名称是 zipkin 。如果你使用的是Kafka ，必须设置相应的 spring.zipkin.sender.type 属性：

spring.zipkin.sender.type: kafka

抽样率, 1为百分之百

spring.sleuth.sampler.pbrobability=1

安装Zipkin

zipkin提供数据存储，可视化页面等功能。

• 使用docker安装

docker run -d -p 9411:9411 openzipkin/zipkin

• 访问地址：http://host:9411
  

• 请求业务接口，并查看跟踪记录
  

Sleuth源码参考

• TraceWebMvcConfigurer

class TraceWebMvcConfigurer implements WebMvcConfigurer {
     
    @Autowired
    ApplicationContext applicationContext;

    TraceWebMvcConfigurer() {
     
    }

    public void addInterceptors(InterceptorRegistry registry) {
     
        registry.addInterceptor((HandlerInterceptor)this.applicationContext.getBean(SpanCustomizingAsyncHandlerInterceptor.class));
    }
}

• SpanCustomizingAsyncHandlerInterceptor

public final class SpanCustomizingAsyncHandlerInterceptor extends HandlerInterceptorAdapter {
     
  @Autowired(required = false)
  HandlerParser handlerParser = new HandlerParser();

  SpanCustomizingAsyncHandlerInterceptor() {
      // hide the ctor so we can change later if needed
  }

  @Override
  //执行请求前处理跟踪数据
  public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object o) {
     
    SpanCustomizer span = (SpanCustomizer) request.getAttribute(SpanCustomizer.class.getName());
    if (span != null) handlerParser.preHandle(request, o, span);
    return true;
  }

  // Set the route attribute on completion to avoid any thread visibility issues reading it
  @Override
  //完成请求后处理跟踪数据
  public void afterCompletion(
    HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
     
    SpanCustomizer span = (SpanCustomizer) request.getAttribute(SpanCustomizer.class.getName());
    if (span != null) setHttpRouteAttribute(request);
  }
}