spring cloud sleuth运用与源码分析

背景介绍

基于分布式架构的环境下， 现在一个完整的调用请求往往会经过很多服务的处理，为了查询一个请求的调用经历过哪些服务，按照如何顺序，所以我们需要一个链路式追踪组件。追踪一个服务的调用所有过程。
开源链路式组件目前有Google的Dapper， 阿里的鹰眼，以及twitter的Zipkin。本文将使用Zipkin，Zipkin是基于的Dapper的基础上开发的。Zipkin 可通过http方式消息传输也可使用中间件MQ。Zipkin的消息存储可以直接存储在内存中，也可持久化到mysql，elasticsearch。

基本术语

spring cloud sleuth沿用Google的Dapper的术语：

• Span:基本工作单元，例如，在一个新建的span中发送一个RPC等同于发送一个回应请求给RPC，span通过一个64位ID唯一标识，trace以另一个64位ID表示，span还有其他数据信息，比如摘要、时间戳事件、关键值注释(tags)、span的ID、以及进度ID(通常是IP地址)，span在不断的启动和停止，同时记录了时间信息，当你创建了一个span，你必须在未来的某个时刻停止它。
• trace:是由众多span组成的树形结构，使用64位标识生成唯一调度ID。
• Annotation：用来及时记录一个事件的存在，一些核心annotations用来定义一个请求的开始和结束：
  　　 1.cs - Client Sent -客户端发起一个请求，这个annotation描述了这个span的开始
  　　 2.sr - Server Received -服务端获得请求并准备开始处理它，如果将其sr减去cs时间戳便可得到网络延迟
  　　 3.ss - Server Sent -注解表明请求处理的完成(当请求返回客户端)，如果ss减去sr时间戳便可得到服务端需要的处理请求时间
  　 　4.cr - Client Received -表明span的结束，客户端成功接收到服务端的回复，如果cr减去cs时间戳便可得到客户端从服务端获取回复的所有所需时间。

(图片来源网络)

从图可知，当一个请求进来，会进过很多服务，每个服务都会生成一个独立的span，但服务都共享一个trace。

基础运用