跨Spring Boot微服务请求传递Correlation Id的最优上下文存储策略

最优方案为第4种：REST场景使用RequestContext、GRPC场景使用原生Context存储，搭配MDC做日志透传补充，是Spring Boot异构接口场景下的首选方案

各方案优劣势详细分析 #

• 方案1：方法签名显式传递上下文
  入侵性极强，所有业务链路的方法（Controller→Service→下游调用封装类）都需要新增上下文参数，老项目改造工作量极大，新增业务逻辑时极易出现漏传问题，完全不符合开闭原则，仅适用于对上下文可控性要求极高的极端特殊场景，普通业务场景完全不推荐。
• 方案2：直接使用MDC存储
  MDC本质是为日志透传设计的ThreadLocal封装，优势是和日志框架天然集成，打印日志时不需要额外编码就能自动携带Correlation-ID。但缺陷明显：默认只支持字符串类型键值对，无法存储复杂结构的上下文数据；异步场景（子线程、线程池调用）默认会丢失上下文，需要额外开发透传逻辑；GRPC场景默认和MDC不打通，需要自行实现拦截器适配，单独使用覆盖场景有限。
• 方案3：直接使用ThreadLocal存储
  属于最底层的实现，MDC、RequestContext本质都是基于ThreadLocal做的封装。直接使用需要自行处理上下文的初始化、销毁逻辑，线程池场景下极易出现内存泄漏、上下文串用（线程复用导致新请求拿到旧请求的上下文）问题，相当于重复造轮子，没有任何额外收益，完全不推荐。
• 方案4：REST场景用RequestContext、GRPC场景用原生Context存储
  是当前场景下的最优解，核心原因如下：
  1. 框架原生管控生命周期，稳定性高：REST场景下Spring的RequestContext本身和请求生命周期绑定，请求结束后自动销毁，不会出现内存泄漏；异步场景下Spring提供了ContextCopyingDecorator可以自动透传上下文到子线程，不需要自行实现。GRPC的Context是GRPC框架原生提供的上下文组件，和GRPC请求生命周期绑定，原生支持跨线程透传，和GRPC拦截器天然适配，不需要额外开发生命周期管理逻辑。
  2. 业务入侵极低：上下文的写入统一在请求拦截器实现，业务代码不需要修改方法签名，需要使用时直接从对应Context读取即可，业务层完全感知不到上下文存储逻辑，符合开闭原则。
  3. 适配性强：同时支持REST、GRPC两种接口场景，支持存储复杂类型的上下文数据，不局限于字符串。
  4. 扩展成本低：只需要在拦截器中把Correlation-ID同时写入Context和MDC，就能同时满足下游调用透传、日志自动打印两个需求，不需要额外改造。

可选补充方案 #

如果项目已经接入了SkyWalking、Jaeger这类全链路追踪组件，也可以直接使用追踪组件原生的链路上下文存储能力，不需要自行开发拦截器写入逻辑，直接从追踪上下文中提取traceId作为Correlation-ID使用即可，适配成本更低。

内容的提问来源于stack exchange，提问作者javacomelava