SpringCloudSleuth之分布式服务跟踪

Spring Cloud 系列

• eureka之服务治理完整过程搭建
• eureka之高可用的注册中心
• eureka之详解
• ribbon之客户端负载均衡
• ribbon之配置详解
• Hystrix之服务容错保护
• Hystrix之使用详解
• Hystrix之请求合并
• Hystrix之仪表盘以及Turbine集群监控
• Feign之声明式服务调用
• Consul之服务发现和配置管理
• Sleuth之分布式服务跟踪
• Zuul之API网关服务
• Config之分布式配置中心
• Config之服务端详解
• Config之客户端详解
• Bus之消息总线
• Stream之消息驱动的微服务
• Stream之绑定器详解
• 重试机制
• 
  

  系列源码地址

---

写在前面

参考官方文档

Spring Cloud Sleuth为Spring Cloud实现了一个分布式跟踪解决方案，大量借鉴了Dapper、 Zipkin和HTrace。对于大多数用户来说，sleuth 应该是不可见的，所有与外部系统的交互都应该是自动检测的。可以简单地在日志中捕获数据，或者将其发送到远程收集器服务。

1. 核心组件

1.1 span

span 是最基本的工作单元。举个例子，存在这样一个服务A，其内部实现调用了服务B。为了完成我们的追踪信息，我们需要考虑如何记录A的调用、B的调用以及怎样将它们串接起来。首先，每一次服务的调用都是一个 span，也就是说服务A的调用会创建一个 span A，服务B的调用也会创建一个 span B，如何将它们串接起来呢？

span B 会包含一个父的id，该id 指向 span A 的id。那么我们需要的一些时间戳等信息呢？span 会存储这些信息，并且官方文档里提到：“span 被启动和停止，它们会记录它们的时间信息。一旦你创建了一个 span，你必须在将来的某个时候停止它”。

开始 trace 的初始 span 称为 root span，该 span 的 id值等于 trace Id。

1.2 trace

trace 像当于上文所提到的整个跟踪链，它能够将多个span 整合起来，形成一个树状结构，实际上是 span 持有了相同的 trace Id。在复杂的分布式系统中，每一个外部请求通常都会产生一个复杂的树状结构的 Trace。

1.3 annotation

它用来及时的记录一个事件的存在。可以把它理解为一个含有时间戳的事件标签。span 中维护了一个 annotation 的 list，按照 annotation 时间戳的升序排序。

• cs: 客户端发送，客户提出了一个请求。此注释指示 span 的开始。
• sr：服务器接收，服务器接收到请求并开始处理它。从这个时间戳减去 cs 时间戳，可以得到网络延迟。
• ss：服务器发送。请求处理完成时(响应被发送回客户机时)注释。从这个时间戳中减去sr时间戳，将显示服务器端处理请求所需的时间。
• cr：客户收到。表示 span 的结束。客户端已经成功接收到来自服务器端的响应。从这个时间戳中减去cs时间戳，就得到客户机从服务器接收响应所需的全部时间

2. sleuth 特性

• 将 trace 和 span id添加到Slf4J MDC，这样就可以在日志聚合器中从给定的 trace 或 span 提取所有日志。

• 提供对常见分布式跟踪数据模型的抽象:trace、spans(形成DAG)、annotations、key-value annotations。松散地基于HTrace，但 与 Zipkin (Dapper)兼容。

• 装备了来自 Spring 应用程序的常见入口点和出口点 （ servlet 过滤器、rest template、scheduled 操作、消息通道，zuul 过滤器，feign client）。

  位于 spring-cloud-sleuth-core 项目下的 org.springframework.cloud.sleuth.instrument 包下。

• 如果 spring-cloud-sleud-zipkin可用，那么该应用程序将通过HTTP生成并收集 zipkin 兼容的跟踪。默认情况下，它将它们发送到本地主机(端口9411)上的 Zipkin 收集器服务。使用 spring.zipkin.baseUrl配置服务的位置。

  这里有常提到的两个开源项目：brave 和 zipkin；从全文文档来看，brave（sleuth 使用了这个 trace 库） 更像是集成到我们的应用程序上，负责收集和发送 trace以及 spans 数据。zipkin 则更像一个服务端，能够处理这些数据，并提供接口；更方便的是，基于这些接口，它开发了一套 UI 界面，我们可以直接查看分布式系统下的跟踪数据了。

3. 使用

讲使用应该是不太合乎道理的，在这里更像是 “目的地”。我们收集了这些信息，它需要去到哪里，需要怎样分析组织，怎样以最直观的方式展现给我们想要的跟踪数据。

3.1 日志

日志的使用方式大概分两种，一种直接在控制台输出 traces 信息，一种存储为日志文件，将由其它的聚集工具分析（kibana 等）。

控制台输出非常简单，引入如下依赖即可 (项目本身已经是一个完整的 spring cloud项目)：

		<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-sleuth</artifactId>
        </dependency>

第二种实现稍许麻烦下，不过也有两种方式，一是直接在将 traces 信息发送到工具，二是将 traces 信息保存为文件，交由工具主动获取分析。

3.2 zipkin

1. 使用 zipkin 需要先引入如下依赖：

   	<dependency>
           <groupId>org.springframework.cloud</groupId>
           <artifactId>spring-cloud-starter-sleuth</artifactId>
       </dependency>        
   	<dependency>
           <groupId>org.springframework.cloud</groupId>
           <artifactId>spring-cloud-sleuth-zipkin</artifactId>
       </dependency>
   

   或者：

   	<dependency>
           <groupId>org.springframework.cloud</groupId>
           <artifactId>spring-cloud-starter-zipkin</artifactId>
       </dependency>        
   

2. 启动 zipkin server（最新稳定版下载地址）：java -jar <jar包名>。

   zipkin server 默认是基于内存来存储跟踪信息的；但它支持了 mysql ，具体参考文档即可。

3. 运行，并启动服务即可，zipkin server 控制台访问地址：http://loaclhost:9411 。