微服务之服务跟踪

介绍

---

当部署的服务越来越多的时候，需要跟踪一个请求从一个服务到下一个微服务的传播过程，Spring Cloud Sleuth正是解决这个问题，它在日志中引入唯一的ID，以保证微服务调用之间的一致性，这样你就可以跟踪某个请求是如何从一个服务传到下一个服务。

为了实现请求跟踪，当请求发送到分布式系统的入口时，只需要服务跟踪框架为该请求创建一个唯一的跟踪标识，同时在分布式内部流转的时候，框架始终保持该ID唯一，直到返回给请求方为止，这个唯一标识就是Trace ID,通过Trace ID的标记，我们就可以将所有请求过程日志关联起来。

为了统计各各处理单元的时间延时，当请求达到各个服务组件的时候，或者当处理逻辑达到某个状态时，也通过唯一的标识来标识它的开始、具体过程以及结束，该标识就是Span ID，对于每个Span来说，它必须有开始和结束二个节点，除了时间戳记录之外，它还可以包含其他元数据。比如：事件名称、请求信息等等。

在Spring boot应用中，在引入Spring-cloud-start-sleuth依赖之后，它会自动的为当前的应用构建起鸽通信的跟踪机制，比如：通过RabbitMQ、Kafka传递请求，通过zuul代理传递请求、通过RestTemplate发起请求。

• Trace

  它是由一组有相同Trace ID的Span串联形成一个树状结构。为了实现请求跟踪，当请求请求到分布式系统的入口端点时，只需要服务跟踪框架为该请求创建一个唯一的跟踪标识，同时在分布式系统内部流转的时候，框架始终保持传递该唯一标识，直到返回请求为止，我们通过它将所有请求过程中的日志关联起来.

• Span

  它代表了一个基础的工作单元，例如服务调用。为了统计各处理单元的时间延迟，当前请求到达各个服务组件时，也通过一个唯一标识来标记它的开始、具体过程以及结束。通过span的开始和结束的时间戳，就能统计该span的时间延迟，除此之外，我们还可以获取如事件名称、请求信息等元数据

• Annotation

  cs - Client Sent - 客户端发送一个请求，这个注解描述了这个Span的开始。

  sr - Server Received - 服务端获得请求并准备开始处理它，其中（sr – cs） 时间戳便可得到网络传输的时间。

  ss - Server Sent （服务端发送响应）– 该注解表明请求处理的完成(当请求返回客户端)， （ss – sr）时间戳就可以得到服务器请求的时间。

  cr - Client Received （客户端接收响应）- 表明此时Span的结束，（cr – cs）时间戳便可以得到整个请求所消耗的时间。

# 追踪类型的组件

---

• scheduling

  原理是AOP处理Scheduled注解，TraceSchedulingAspect可以带出，只要是在IOC容器中的Bean带有@Scheduled注解的方法的调用都会被sleuth处理

• messaging

  原理是基于spring messaging的ChannelInterceptor。
  TraceChannelInterceptor/IntegrationTraceChannelInterceptor
  MessagingSpanTextMapExtractor和MessagingSpanTextMapInjector

• Hystrix

  原理是使用HystrixPlugins添加trace相关的plugin，自定义了一个HystrixConcurrencyStrategy的实现，SleuthHystrixConcurrencyStrategy。

• Feign

  原理是实现了两个Feign Client实例，一个不带Ribbon TraceFeignClient、一个带Ribbon，TraceLoadBalancerFeignClient
  TraceFeignAspect AOP里面的逻辑是，有地方想获取Client实例，就拦截返回自己封装的Client。

• async

  @Async注解和ThreadPoolTaskExecutor下面的类。

• RestTemplate

  原理是spring client的Interceptor机制。

• Zuul

  原理是zuul的Filter机制，ZuulFilter，实现了三个TracePreZuulFilter、TracePostZuulFilter两个Filter。