【九月打卡】第6天 服务调用链追踪-Sleuth

课程名称：Java架构师-技术专家
课程章节： 阶段四 · 服务调用链追踪、消息驱动
课程讲师： 慕课讲师团队

课程内容

链路追踪原理进阶

sleuth自启动

Sleuth是整个Spring Cloud中最干净的组件。干净到什么程度？你不用做任何配置，也不用加什么注解标签，只要引入Sleuth的依赖到pom里，项目就自动具备了链路追踪功能。正所谓明枪易躲暗箭难防，好歹其他组件有一个启动注解挂在我们main方法的类上，我们知道怎么来顺藤摸瓜进行学习，可是碰到Sleuth这种行踪隐蔽的组件我们应该如何下手？这里的启动机关在哪里？

对Sleuth这类静默启动的组件来说，找入门机关有一个诀窍，那么就是查找“AutoConfiguration”关键字，一准跑不了（对Spring Cloud中其他组件用这个法子也管用）。顺着这个思路，我们就找到了TraceAutoConfiguration自启动类，它是Sleuth最顶层的自动装配类，Sleuth的静默启动就是靠着这个类上面的一行配置：

@ConditionalOnProperty(value="spring.sleuth.enabled", matchIfMissing=true)

@ConditionalOnProperty注解的意思是，由指定配置项的值来决定是否开启自动配置。而”matchIfMissing=true“的意思是，假如我们没有主动声明关闭Sleuth功能的话（spring.sleuth.enabled=false），那么默认开启链路追踪功能。在TraceAutoConfiguration主类加载完成后，还会陆续启动后置的几个自动配置类，这部分内容会在稍后的源码阅读环节详细说明。
如果同学们需要在项目里研发类似Sleuth这样非业务性质的辅助模块，建议也可以小炫技一把，使用这种静默自启动的方式，让人感受一种”事了拂衣去，深藏功与名“的境界。

链路追踪适配方案

我们知道Spring Cloud在上下游调用中会涉及到多种不同的组件，每个组件的玩法都不一样，有的组件使用HTTP协议，有的采用WebSocket协议，有的使用RxJava，还有的用WebFlux。而每种协议/调用方式用来传递信息的姿势也各不相同。在这个情况下，Sleuth发扬了兵来将挡水来土掩的做法，定义了一系列五花八门的适配方案，具体可以参见org.springframework.cloud.sleuth.instrument下的package，也就是上图中选中的"instrument"包下的内容，每个子package里封装了一套特殊适配器，用来抽取特定调用方式的链路信息。比如“hystrix”包中的适配器就是专门应付Hystrix组件的，而“messaging”包是专门适配消息组件的。

Sleuth为了对接各式各样的协议和组件，真是花了大工夫来做适配，为的就是能捕捉到调用链路在不同组件间传递的细节信息。比如说我们通过Spring WebFlux调用了服务A，然后服务A又调用了消息组件，由于Sleuth分别对WebFlux和Messaging的流程都做了适配，因此就可以为这两个环节创建Span并记录链路数据，假如某个环节没有被适配到，那这个环节的调用过程就无法被抽取成一个Span，也就无法体现在最终的调用链路中。

Sleuth中的每个适配方案实现方式都大相径庭，但是主线步骤遵循了同样的三步走原则：

• 每个适配方案都通过一个自动装配类来加载独有的配置项或初始化核心类，比如RxJava（Hystrix中绕来绕去的回调函数还记得吗？）的适配器有对应的RxJavaAutoConfiguration，WebFlux（Gateway底层的实现方式还记得吗？）的适配器有对应的TraceWebFluxAutoConfiguration
• 创建新的Span，与上游Span做关联，将链路信息加入到当前Span中
• 比如HTTP的适配方案是通过在HTTP Header里写入特殊标签的方式来做的，而消息组件是通过向Message Header写入数据来传递信息。对于其他不同的适配方案来说，传递参数的方式各有不同

课程收获

今天学习的收获是

• 链路追踪原理进阶