Spring Cloud构建微服务架构:分布式服务跟踪

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

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

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

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

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

通过诸如RabbitMQ、Kafka(或者其他任何Spring Cloud Stream绑定器实现的消息中间件)传递的请求

通过Zuul代理传递的请求

通过 发起的请求

在快速入门示例中,由于 对 发起的请求是通过 实现的,所以 组件会对该请求进行处理,在发送到 之前sleuth会为在该请求的Header中增加实现跟踪需要的重要信息,主要有下面这几个(更多关于头信息的定义我们可以通过查看 的源码获取):

X-B3-TraceId:一条请求链路(Trace)的唯一标识,必须值

X-B3-SpanId:一个工作单元(Span)的唯一标识,必须值

X-B3-ParentSpanId::标识当前工作单元所属的上一个工作单元,Root Span(请求链路的第一个工作单元)的该值为空

X-B3-Sampled:是否被抽样输出的标志,1表示需要被输出,0表示不需要被输出

X-Span-Name:工作单元的名称

我们可以通过对 的实现做一些修改来输出这些头部信息,具体如下:

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

为了更直观的观察跟踪信息,我们还可以在 中增加下面的配置:

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

完整示例:

读者可以根据喜好选择下面的两个仓库中查看 和 两个项目:

Github:https://github.com/dyc87112/SpringCloud-Learning/

Gitee:https://gitee.com/didispace/SpringCloud-Learning/

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

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

更多内容,请点击《Spring Cloud微服务架构汇总》

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180220G0EDDS00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券