SpringCloud升级之路2020.0.x版-44.避免链路信息丢失做的设计(1)

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent

我们在这一节首先分析下 Spring Cloud Gateway 一些其他可能丢失链路信息的点，之后来做一些可以避免链路信息丢失的设计，之后基于这个设计去实现我们需要的一些定制化的 GlobalFilter

Spring Cloud Gateway 其他的可能丢失链路信息的点

经过前面的分析，我们可以看出，不止这里，还有其他地方会导致 Spring Cloud Sleuth 的链路追踪信息消失，这里举几个大家常见的例子：

1.在 GatewayFilter 中指定了异步执行某些任务，由于线程切换了，并且这时候可能 Span 已经结束了，所以没有链路信息，例如：

@Overridepublic Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {return chain.filter(exchange).publishOn(Schedulers.parallel()).doOnSuccess(o -> {//这里就没有链路信息了log.info("success");});}

2.将 GatewayFilter 中继续链路的

chain.filter(exchange)

放到了异步任务中执行，上面的 AdaptCachedBodyGlobalFilter 就属于这种情况，这样会导致之后的 GatewayFilter 都没有链路信息，例如：

@Overridepublic Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {return Mono.delay(Duration.ofSeconds(1)).then(chain.filter(exchange));}

Java 并发编程模型与 Project Reactor 编程模型的冲突思考

Java 中的很多框架，都用到了 ThreadLocal，或者通过 Thread 来标识唯一性。例如：

日志框架中的 MDC，一般都是 ThreadLocal 实现。
所有的锁、基于 AQS 的数据结构，都是通过 Thread 的属性来唯一标识谁获取到了锁的。
分布式锁等数据结构，也是通过 Thread 的属性来唯一标识谁获取到了锁的，例如 Redisson 中分布式 Redis 锁的实现。

但是放到 Project Reactor 编程模型，这就显得格格不入了，因为 Project Reactor 异步响应式编程就是不固定线程，没法保证提交任务和回调能在同一个线程，所以 ThreadLocal 的语义在这里很难成立。Project Reactor 虽然提供了对标 ThreadLocal 的 Context，但是主流框架还没有兼容这个 Context，所以给 Spring Cloud Sleuth 粘合这些链路追踪带来了很大困难，因为 MDC 是一个 ThreadLocal 的 Map 实现，而不是基于 Context 的 Map。这就需要 Spring Cloud Sleuth 在订阅一开始，就需要将链路信息放入 MDC，同时还需要保证运行时不切换线程。

运行不切换线程，这样其实限制了 Project Reactor 的灵活调度，是有一些性能损失的。我们其实想尽量就算加入了链路追踪信息，也不用强制运行不切换线程。但是 Spring Cloud Sleuth 是非侵入式设计，很难实现这一点。但是对于我们自己业务的使用，我们可以定制一些编程规范，来保证大家写的代码不丢失链路信息。

可以从哪里获取当前请求的 Span

Spring Cloud Sleuth 的链路信息核心即 Span，在之前的源码分析中，我们知道，在入口的 WebFilter 中，

TraceWebFilter

生成 Span 并将其放入本次 HTTP 请求响应抽象的

ServerWebExchange

的 attributes 中：

TraceWebFilter.java

protected static final String TRACE_REQUEST_ATTR = Span.class.getName();private Span findOrCreateSpan(Context c) {Span span;AssertingSpan assertingSpan = null;//如果当前 Reactor 的上下文中有 Span，就用这个 Spanif (c.hasKey(Span.class)) {Span parent = c.get(Span.class);try (Tracer.SpanInScope spanInScope = this.tracer.withSpan(parent)) {span = this.tracer.nextSpan();}if (log.isDebugEnabled()) {log.debug("Found span in reactor context" + span);}}else {//如果当前请求中本身包含 span 信息，就用这个 span 启动一个新的子 spanif (this.span != null) {try (Tracer.SpanInScope spanInScope = this.tracer.withSpan(this.span)) {span = this.tracer.nextSpan();}if (log.isDebugEnabled()) {log.debug("Found span in attribute " + span);}}//从当前所处的上下文中获取 spanspan = this.spanFromContextRetriever.findSpan(c);//没获取到就新生成一个if (this.span == null && span == null) {span = this.handler.handleReceive(new WrappedRequest(this.exchange.getRequest()));if (log.isDebugEnabled()) {log.debug("Handled receive of span " + span);}}else if (log.isDebugEnabled()) {log.debug("Found tracer specific span in reactor context [" + span + "]");}assertingSpan = SleuthWebSpan.WEB_FILTER_SPAN.wrap(span);//将 span 放入 `ServerWebExchange` 的 attributes 中this.exchange.getAttributes().put(TRACE_REQUEST_ATTR, assertingSpan);}if (assertingSpan == null) {assertingSpan = SleuthWebSpan.WEB_FILTER_SPAN.wrap(span);}return assertingSpan;}

这样可以看出，我们在编写 GlobalFilter 的时候可以通过读取

ServerWebExchange

的 attributes 获取当前链路信息的 Span。但是

TRACE_REQUEST_ATTR

是 protected 的，我们可以下面这个工具类将其暴露出来。

package com.github.jojotech.spring.cloud.apigateway.common;import org.springframework.cloud.sleuth.CurrentTraceContext;import org.springframework.cloud.sleuth.Tracer;import org.springframework.cloud.sleuth.http.HttpServerHandler;import org.springframework.cloud.sleuth.instrument.web.TraceWebFilter;public class TraceWebFilterUtil extends TraceWebFilter {public static final String TRACE_REQUEST_ATTR = TraceWebFilter.TRACE_REQUEST_ATTR;//仅仅为了暴露 TraceWebFilter 的 TRACE_REQUEST_ATTR 使用的工具类private TraceWebFilterUtil(Tracer tracer, HttpServerHandler handler, CurrentTraceContext currentTraceContext) {super(tracer, handler, currentTraceContext);}}

下一节，我们将继续讲解避免链路信息丢失做的设计，主要针对获取到现有 Span 之后，如何保证每个 GlobalFilter 都能保持链路信息。

微信搜索“我的编程喵”关注公众号，每日一刷，轻松提升技术，斩获各种offer：