Sleuth 体系架构：为什么微服务架构需要链路追踪？

Sleuth 体系架构：为什么微服务架构需要链路追踪？

俗话说，人非圣贤孰能无过，你有过来我有过，微服务它也有过。

所谓“过”，便是这线上环境所发生的 Bug。面对线上 Bug 怎么办？有则改之，无则加勉而已。Sentinel 用自己的文治武功替我们搞定了后半句“无则加勉”。那么这前半句“有则改之”，我们该如何下手去改呢？

请你想一下，在改正线上 Bug 之前，咱们是不是需要先找到 Bug 发生的原因呢？所以今天就来聊一聊“如何找 Bug”这个话题，且看我是如何使用 Sleuth 提供的“调用链追踪”技术，按图索骥查明 Bug 真相的。

首先我来带你了解一下调用链追踪要解决的问题。

调用链追踪解决了什么问题

我们可以想象这样一个场景，你负责的是一个庞大的电商微服务架构系统，每个服务之间都有复杂的上下游调用关系，而且并发量还不小，每秒上万 QPS 不在话下。

在这个微服务系统中，用户通过浏览器的 H5 页面访问系统，这个用户请求会先抵达微服务网关组件，然后网关再把请求分发给各个微服务。所以你会发现，用户请求从发起到结束要经历很多个微服务的处理，这里面还涉及到消息组件的集成。

我画了一幅图来展示这个复杂的关系。

现在问题来了，突然有一天，有用户上报，说他在页面端看到了一个报错，每次点击下单都会报一个 500 错误。如果问题被交到了你手上，你该怎么排查呢？作为开发人员我们知道 500 错误是 Internal Server Error，这个异常可能发生在任何阶段，就算在同一时刻也可能有多条不同服务的 Error 日志。在一个没有链路追踪的微服务系统里，线上 Bug 排查无异于大海捞针，因为你根本无法梳理出一次请求的前后调用链。

因为缺少订单 ID 之类的唯一主键，你就很难缩小排查范围，只能耗费大量的时间用肉眼走查每一条日志。你需要找到用户所有下单记录的起始 log，从前往后挨个摸排，从蛛丝马迹中梳理服务调用之间的关系并定位最终的问题，可见这种方式十分低效。

如果你想提高线上异常排查的效率，那么首先要做的一件事就是：将一次调用请求中所有访问到的微服务日志前后串联起来。这就像拔出萝卜带出泥一样，只要你找到了本次调用的任何一条日志，你就可以顺藤摸瓜将前后的关联日志信息全部找到。这就是“调用链追踪”技术要完成的工作了。

那么调用链追踪是如何实现日志信息串联的呢？简单来说，链路追踪技术会为每次服务调用生成一个全局唯一的 ID（后面我们叫它 Trace ID），从本次服务调用的起点到终点，这个过程中的所有日志信息都会被打上 Trace ID 的烙印。这样一来，根据日志中的 Trace ID，我们就能很清晰地梳理出一次服务请求前后都经过了哪些微服务节点。

就像下面这张图一样，我们将调用链追踪应用到线上 Bug 排查的场景之后，一整条调用链（实线箭头）已是跃然纸上。我们只要找出当前用户下单请求的任意一条日志，就能根据这条日志中的 Trace ID 将整个调用链拎出来，到底是哪个服务调用环节的异常导致了用户下单失败，我们也就一目了然了。

到这里，相信你已经对调用链追踪所要解决的问题有了清晰的认识。那么接下来，我就带你了解一下 Spring Cloud 的链路追踪组件 Sleuth 是如何实现链路追踪的，也就是分析它的底层逻辑。

Sleuth 的底层逻辑调用链追踪有两个任务，一是标记出一次调用请求中的所有日志，二是梳理日志间的前后关系。前面我提到了一个 Trace ID，它是用来标记调用链的全局唯一 ID。你一定可以联想到，Trace ID 完成的是第一个任务：标记。不过呢，Trace ID 并不能表达日志信息的前后关系，那么 Sleuth 是如何解决这个问题的呢？

Sleuth 是通过打入到 Log 中的“卧底”来串联前后日志的。你集成了 Sleuth 组件之后，它会向你的日志中打入三个“特殊标记”，其中一个标记你应该已经清楚了，那便是 Trace ID。剩下的两个标记分别是 Span ID 和 Parent Span ID，这俩用来表示调用的前后顺序关系。

所谓 Span，它是 Sleuth 下面的一个基本工作单元，当服务请求抵达当前单元时，Sleuth 就会为这个单元分配一个独一无二的 Span ID，并标记单元的开始时间和结束时间，这样就可以记录每个单元的处理用时了。

而 Parent Span ID 呢，顾名思义，它指向了当前单元的父级单元，也就是上游的调用者。一个环环相扣的调用链就通过 Parent Span ID 被串了起来。为了让你更加形象地理解 Trace ID、Span ID 和 Parent Span ID 在调用链中的作用，我画了一个简化了服务调用的模拟流程图，带你梳理每一个调用步骤中的日志标记变化。

从上面的图中可以看出，这个服务请求调用了三个微服务，分别为服务 A、服务 B 和服务 C。在一条调用链中，不管你调用了多少个微服务，Sleuth 为本次调用生成的全局唯一 Trace ID 都会贯穿整个链路，所图中三个微服务所对应的日志 Trace ID 都是 A1。

由于服务 A 是调用链的起点，所以它并没有父级单元，因此它的 Parent Span ID 为空，而起始单元的 Span ID 和 Trace ID 则是相同的，值都为 A1。

对于服务 B 来说，它的父级调用单元是服务 A，因此它的 Parent Span ID 指向了服务 A 的 Span ID，即 A1；

同理，服务 C 的 Parent Span ID 指向了服务 B 的 Span ID，即 B2。

当然啦，上面的图示只是一个简化的流程，在实际的项目中，一次服务调用可不光只会生成一个 Span。比如说服务 A 请求通过 OpenFeign 组件调用了服务 B，那么服务 A 接收用户请求的过程就是一个单元，而 OpenFeign 组件发起远程调用的过程又是另一个单元。

由此可见，单元的颗粒度其实是非常小的，在下节课我再通过实战让你近距离观察调用链中的单元分布。通过这些 Sleuth 的特殊标记，我们就可以根据时间顺序，将一次服务请求经过的调用节点都梳理出来，这样你就能迅速发现报错信息发生在哪个阶段。这里我放了一张下节课的剧透图片，这是使用 Zipkin 生成的链路追踪的可视化信息。你可以看出，每个服务调用都以时间先后顺序规整好了，红色的部分就是发生线上 Exception 的服务。 

除了 Trace 和 Span 之外，Sleuth 还有一个特殊的数据结构，叫做 Annotation，被用来记录一个具体的“事件”。我把 Sleuth 所支持的四种事件做成了一个表格，你可以参考一下。

 

 在这里我举个例子，来帮你理解怎么使用这四种事件。

以服务 A 调用服务 B 的场景来说，服务 A 是一个 Client，也就是发起调用的一方，而服务 B 是一个 Server，也就是处理请求的一方。

如果你用服务 B 的 ss 减去 sr，你就可以得到请求在服务 B 阶段的处理时间；如果用服务 B 的 sr 减去服务 A 的 cs，就可以得到服务 A 到服务 B 之间的网络调用延迟时间；如果用服务 A 的 cr 减去 cs，就可以得到当次请求从发起到结束所花费的总时间。

到这里，相信你已经对 Sleuth 的链路打标原理十分了解了。