Spring Cloud构建微服务架构：分布式服务跟踪（跟踪原理）【Dalston版】

通过上一篇《分布式服务跟踪（入门）》的例子，我们已经通过Spring Cloud Sleuth往微服务应用中添加了实现分布式跟踪具备的基本要素。下面通过本文来详细说说实现分布式服务跟踪的一些要点。

分布式系统中的服务跟踪在理论上并不复杂，它主要包括下面两个关键点：

为了实现请求跟踪，当请求发送到分布式系统的入口端点时，只需要服务跟踪框架为该请求创建一个唯一的跟踪标识，同时在分布式系统内部流转的时候，框架始终保持传递该唯一标识，直到返回给请求方为止，这个唯一标识就是前文中提到的Trace ID。通过Trace ID的记录，我们就能将所有请求过程日志关联起来。
为了统计各处理单元的时间延迟，当请求达到各个服务组件时，或是处理逻辑到达某个状态时，也通过一个唯一标识来标记它的开始、具体过程以及结束，该标识就是我们前文中提到的Span ID，对于每个Span来说，它必须有开始和结束两个节点，通过记录开始Span和结束Span的时间戳，就能统计出该Span的时间延迟，除了时间戳记录之外，它还可以包含一些其他元数据，比如：事件名称、请求信息等。

在快速入门示例中，我们轻松实现了日志级别的跟踪信息接入，这完全归功于spring-cloud-starter-sleuth组件的实现。在Spring Boot应用中，通过在工程中引入spring-cloud-starter-sleuth依赖之后，它会自动的为当前应用构建起各通信通道的跟踪机制，比如：

通过诸如RabbitMQ、Kafka（或者其他任何Spring Cloud Stream绑定器实现的消息中间件）传递的请求
通过Zuul代理传递的请求
通过RestTemplate发起的请求

在快速入门示例中，由于trace-1对trace-2发起的请求是通过RestTemplate实现的，所以spring-cloud-starter-sleuth组件会对该请求进行处理，在发送到trace-2之前sleuth会为在该请求的Header中增加实现跟踪需要的重要信息，主要有下面这几个（更多关于头信息的定义我们可以通过查看org.springframework.cloud.sleuth.Span的源码获取）：

X-B3-TraceId：一条请求链路（Trace）的唯一标识，必须值
X-B3-SpanId：一个工作单元（Span）的唯一标识，必须值
X-B3-ParentSpanId:：标识当前工作单元所属的上一个工作单元，Root Span（请求链路的第一个工作单元）的该值为空
X-B3-Sampled：是否被抽样输出的标志，1表示需要被输出，0表示不需要被输出
X-Span-Name：工作单元的名称

我们可以通过对trace-2的实现做一些修改来输出这些头部信息，具体如下：

@RequestMapping(value = "/trace-2", method = RequestMethod.GET)public String trace(HttpServletRequest request) {    logger.info("===<call trace-2, TraceId={}, SpanId={}>===",            request.getHeader("X-B3-TraceId"), request.getHeader("X-B3-SpanId")); return "Trace";}

通过上面的改造，我们再运行快速入门的示例内容，并发起对trace-1的接口访问，我们可以得到如下输出内容。其中在trace-2的控制台中，输出了当前正在处理的TraceID和SpanId信息。

-- trace-1INFO [trace-1,a6e9175ffd5d2c88,8524f519b8a9e399,true] 10532 --- [nio-9101-exec-2] icationEnhancerBySpringCGLIB27aa9624 : ===<call trace-1>===

-- trace-2INFO [trace-2,a6e9175ffd5d2c88,ce60dcf1e2ed918f,true] 1208 --- [nio-9102-exec-3] icationEnhancerBySpringCGLIBa7d84797 : ===<call trace-2, TraceId=a6e9175ffd5d2c88, SpanId=be4949ec115e554e>===

为了更直观的观察跟踪信息，我们还可以在application.properties中增加下面的配置：

logging.level.org.springframework.web.servlet.DispatcherServlet=DEBUG

通过将Spring MVC的请求分发日志级别调整为DEBUG级别，我们可以看到更多跟踪信息：

-- trace-12016-11-27 09:26:52.663 DEBUG [trace-1,a6e9175ffd5d2c88,a6e9175ffd5d2c88,true] 10532 --- [nio-9101-exec-2] o.s.web.servlet.DispatcherServlet        : DispatcherServlet with name 'dispatcherServlet' processing GET request for [/trace-1]2016-11-27 09:26:52.666 DEBUG [trace-1,a6e9175ffd5d2c88,a6e9175ffd5d2c88,true] 10532 --- [nio-9101-exec-2] o.s.web.servlet.DispatcherServlet        : Last-Modified value for [/trace-1] is: -12016-11-27 09:26:52.685 DEBUG [trace-1,a6e9175ffd5d2c88,8524f519b8a9e399,true] 10532 --- [nio-9101-exec-2] o.s.web.servlet.DispatcherServlet        : Null ModelAndView returned to DispatcherServlet with name 'dispatcherServlet': assuming HandlerAdapter completed request handling2016-11-27 09:26:52.685 DEBUG [trace-1,a6e9175ffd5d2c88,a6e9175ffd5d2c88,true] 10532 --- [nio-9101-exec-2] o.s.web.servlet.DispatcherServlet        : Successfully completed request

-- trace-22016-11-27 09:26:52.673 DEBUG [trace-2,a6e9175ffd5d2c88,be4949ec115e554e,true] 1208 --- [nio-9102-exec-3] o.s.web.servlet.DispatcherServlet        : DispatcherServlet with name 'dispatcherServlet' processing GET request for [/trace-2]2016-11-27 09:26:52.679 DEBUG [trace-2,a6e9175ffd5d2c88,be4949ec115e554e,true] 1208 --- [nio-9102-exec-3] o.s.web.servlet.DispatcherServlet        : Last-Modified value for [/trace-2] is: -12016-11-27 09:26:52.682 DEBUG [trace-2,a6e9175ffd5d2c88,ce60dcf1e2ed918f,true] 1208 --- [nio-9102-exec-3] o.s.web.servlet.DispatcherServlet        : Null ModelAndView returned to DispatcherServlet with name 'dispatcherServlet': assuming HandlerAdapter completed request handling2016-11-27 09:26:52.683 DEBUG [trace-2,a6e9175ffd5d2c88,be4949ec115e554e,true] 1208 --- [nio-9102-exec-3] o.s.web.servlet.DispatcherServlet        : Successfully completed request

本文完整示例：

读者可以根据喜好选择下面的两个仓库中查看trace-1和trace-2两个项目：

Github：https://github.com/dyc87112/SpringCloud-Learning/
Gitee：https://gitee.com/didispace/SpringCloud-Learning/

如果您对这些感兴趣，欢迎star、follow、收藏、转发给予支持！

本文内容部分节选自我的《Spring Cloud微服务实战》，但对依赖的Spring Boot和Spring Cloud版本做了升级。

Spring Cloud构建微服务架构：分布式服务跟踪（跟踪原理）【Dalston版】相关推荐

Spring Cloud构建微服务架构：分布式服务跟踪（整合zipkin）【Dalston版】
通过上一篇<分布式服务跟踪(整合logstash)>,我们虽然已经能够利用ELK平台提供的收集.存储.搜索等强大功能,对跟踪信息的管理和使用已经变得非常便利.但是,在ELK平台中的数据分析 ...
Spring Cloud构建微服务架构：分布式服务跟踪（整合logstash）【Dalston版】
通过之前的<入门示例>,我们已经为两个由SpringCloud构建的微服务项目 trace-1和 trace-2引入了Spring Cloud Sleuth的基础模块 spring-clo ...
Spring Cloud构建微服务架构：分布式服务跟踪（跟踪原理）
通过上一篇<分布式服务跟踪(入门)>的例子,我们已经通过Spring Cloud Sleuth往微服务应用中添加了实现分布式跟踪具备的基本要素.下面通过本文来详细说说实现分布式服务跟踪的一 ...
Spring Cloud构建微服务架构：分布式配置中心【Dalston版】
Spring Cloud Config是Spring Cloud团队创建的一个全新项目,用来为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持,它分为服务端与客户端两个部分.其中服务端也称为 ...
Spring Cloud构建微服务架构：服务容错保护（Hystrix断路器）
断路器断路器模式源于Martin Fowler的Circuit Breaker一文."断路器"本身是一种开关装置,用于在电路上保护线路过载,当线路中有电器发生短路时," ...
Spring Cloud构建微服务架构（七）消息总线（续：Kafka）
Spring Cloud Bus除了支持RabbitMQ的自动化配置之外,还支持现在被广泛应用的Kafka.在本文中,我们将搭建一个Kafka的本地环境,并通过它来尝试使用Spring Cloud B ...
Spring Cloud构建微服务架构：服务容错保护（Hystrix服务降级）【Dalston版】
前言在微服务架构中,我们将系统拆分成了一个个的服务单元,各单元应用间通过服务注册与订阅的方式互相依赖.由于每个单元都在不同的进程中运行,依赖通过远程调用的方式执行,这样就有可能因为网络原因或是依赖服 ...
Spring Cloud构建微服务架构：服务容错保护（Hystrix依赖隔离）【Dalston版】
前言在上一篇<Spring Cloud构建微服务架构:服务容错保护(Hystrix服务降级)>中,我们已经体验了如何使用@HystrixCommand来为一个依赖资源定义服务降级逻辑.实 ...
Spring Cloud构建微服务架构：服务容错保护（Hystrix断路器）【Dalston版】
前言在前两篇<Spring Cloud构建微服务架构:服务容错保护(Hystrix服务降级)>和<Spring Cloud构建微服务架构:服务容错保护(Hystrix依赖隔离)&g ...
Spring Cloud构建微服务架构：Hystrix监控面板【Dalston版】
在上一篇<服务容错保护(hystrix断路器)>的介绍中,我们提到断路器是根据一段时间窗内的请求情况来判断并操作断路器的打开和关闭状态的.而这些请求情况的指标信息都是HystrixComm ...

Spring Cloud构建微服务架构：分布式服务跟踪（跟踪原理）【Dalston版】

本文完整示例：

Spring Cloud构建微服务架构：分布式服务跟踪（跟踪原理）【Dalston版】相关推荐

最新文章

热门文章