dubbo3+sleuth+brave实现链路追踪及traceId未传递或不对应的原因分析

最新推荐文章于 2025-10-23 15:19:08 发布
原创 最新推荐文章于 2025-10-23 15:19:08 发布 · 1.1k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#dubbo #spring cloud

本文讲述了作者在从SpringCloudAlibaba+dubbo2+nacos1.4升级到dubbo3+nacos2的过程中遇到的链路追踪问题，以及通过修改brave.dubbo.TracingFilter解决服务消费者和服务提供者间traceId和spanId传递的问题。
部署运行你感兴趣的模型镜像

问题场景

笔者之前一直使用SpringCloud Alibaba + dubbo2 + nacos1.4进行开发，但是目前naocs2、dubbo3也已经推出有一段时间并逐渐达到生产环境可用状态，所以笔者也希望用最新版本的nacos2及dubbo3尝尝鲜。但在搭建框架的过程中遇到了链路追踪的问题，所以在这里详细记录一下。

SpringCloud Alibaba + dubbo2 + nacos1

笔者基于dubbo2和nacos1的框架的依赖版本如下（这里只展示链路追踪相关依赖）：

SpringCloud Alibaba 2.2.5.RELEASE
Springboot 2.3.7.RELEASE
Dubbo 2.7.8 
Nacos 1.4.3
spring-cloud-starter-sleuth 3.0.0
brave-instrumentation-dubbo 5.13.7

基于dubbo2和nacos1，该依赖版本网上都有较为成熟的搭建方案。直接引入依赖，按照度娘上的配置一下yml文件，就能实现链路追踪，配置过程不太困难。这里就不详细介绍了。

SpringCloud Alibaba + dubbo3 + nacos2

在搭建基于dubbo3和nacos2的框架时也希望能实现链路追踪。其中方案一和方案二是目前Dubbo3官方手册列举的实现方案。
方案一：Skywalking
听说是最简单的，但因为要额外部署Skywalking，所以我暂未尝试这种方案。
方案二：OpenTelemetry或brave
我根据dubbo3的文档进行依赖的引入和yml文件的配置，但是发现服务提供者日志正常写入了traceId和spanId，但服务消费者无论traceId还是spanId都没写入，这个在dubbo的GitHub issue中也未有人提问，所以最终也没找到解决方案。
方案三：sleuth+brave
我尝试了沿用SpringCloud Alibaba + dubbo2 + nacos1框架时的sleuth+brave方案实现链路追踪，但我引入sleuth+brave并根据SpringCloud Alibaba + dubbo2 + nacos1框架时的yml文件配置后，发现虽然服务消费者和服务提供者的日志都写入了traceId和spanId但两个服务的traceId不一致，变成各写各的了，整个追踪链条并未正确串联起来。 最终通过查找GitHub上的issue终于找到一个brave的dubbo2扩展能兼容dubbo3的解决方案，在这里感谢@ShenFeng312这位大佬。
GitHub issue的comment链接如下：
https://github.com/apache/dubbo/issues/11650#issuecomment-1446313706

解决方案

笔者用的依赖版本如下：

SpringCloud Alibaba 2021.0.5.0
Springboot 2.7.8
Dubbo 3.2.4 
Nacos 2.2.0
spring-cloud-starter-sleuth 3.1.9
brave-instrumentation-dubbo 5.16.0

解决方案非常简单，只需修改一行源码即可。
修改brave.dubbo.TracingFilter#invoke中的RpcContext.getContext().getAttachments()改为invocation.getAttachments()
修改前：
在这里插入图片描述
修改后：
在这里插入图片描述
PS： 因为是要修改依赖的源码，所以各位读者可以复制该类、修改这行、增加Dubbo的SPI来指向自定义的TracingFilter。又或者自行重新打包jar。这里就不详细叙述了。

原因

根据GitHub上https://github.com/apache/dubbo/issues/11650#issuecomment-1446313706中@ShenFeng312大佬的分析，主要是因为dubbo2和dubbo3的RpcContext中invcation的attachment属性的实现方式改变了导致的。从issue的回复中其实也看到@ShenFeng312大佬也向brave提交了merge request，让brave-instrumentation-dubbo能兼容dubbo3，但是brave的开发人员一直未同意合并，这里就不展开说了，大家有兴趣可以自行去GitHub上看看。

疑问

根据知其然，也要知其所以然的想法，我尝试分析其中的原因，但也产生了一些疑问，以下疑问也会在后续的排查过程中逐一解答。

疑问一：dubbo2中为什么直接用RpcContext.getContext().getAttachments()就能传递traceId而不用invocation.getAttachments()呢？
疑问二：为什么dubbo3中brave.dubbo.TracingFilter继续用RpcContext.getContext().getAttachments()是不行的呢？
疑问三：dubbo3中的RpcContext.getContext().getAttachments()和invocation.getAttachments()有什么区别？

排查过程

追踪brave.dubbo.TracingFilter#invoke方法的try…catch…部分可以看到，最终传递到下一个服务的参数是通过invocation的，而traceId和spanId是保存在invocation的attachment这个map中的。所以我们接下来排查的目标都是检查并验证最终invoke时invocation的attachment中有没有traceId和spanId为准。
在这里插入图片描述

排查疑问一：

在这里插入图片描述
根据上述思路及brave.dubbo.TracingFilter#invoke方法中的注释得知，其实clientHandler.handleSendWithParent(clientRequest, invocationContext)一直都只是在操作RpcContext.getContext()的attachment并未操作invocation中的attachment
在这里插入图片描述
而invocation中的attachment其实是直到invoker.invoke(invocation)时才在org.apache.dubbo.rpc.protocol.AbstractInvoker#invoke方法把RpcContext.getContext()的attachment注入到invocation中的attachment中
在这里插入图片描述
所以通过上面的代码跟踪可以发现，dubbo2中虽然一直都是在操作RpcContext.getContext()的attachment，但会在AbstractInvoker#invoke方法中invoke下一个服务的前一刻把RpcCotext.getContext()的attachment注入到invocation中的attachment中，最终还是通过invocation中的attachment传递traceId给下一个服务的。
综上所述，在dubbo2中通过RpcContext.getContext().getAttachments()来操作RpcContext的attachment最终都会在AbstractInvoker#invoke方法里被注入到invocation中的attachment中，所以dubbo2中是可以通过RpcContext.getContext().getAttachments()来传递traceId的

排查疑问二、三：

追踪dubbo3中的RpcContext.getContext().getAttachments()：
在这里插入图片描述
比对dubbo2中的RpcContext.getContext().getAttachments()：
在这里插入图片描述
通过比较dubbo3和dubbo2的RpcContext.getContext().getAttachments()的实现，可以发现，dubbo3实现方式完全不同了，这个改动在dubbo3的官方手册中其实是有提及的
在这里插入图片描述
正是因为RpcContext.getContext().getAttachments()的实现改动，dubbo3中RpcContext.getContext().getAttachments()返回的不是RpcContext中的attachment也不是invocation中的attachment。而是把RpcContext中的SERVER_ATTACHMENT、CLIENT_ATTACHMENT复制一份并返回。后面再怎么put参数进RpcContext中的attachment都没有用了，即使后面在AbstractInvoker#invoke方法中把RpcContext中的attachment注入进invocation的attachment也没用了，因为put参数的时候是put进RpcContext的attachment的副本，而不是RpcContext中的attachment本身
而且！ 本身dubbo3中AbstractInvoker#invoke方法中把RpcContext中的attachment注入invocation的attachment的实现也变了
在这里插入图片描述
不过这里已经不重要了，因为put参数的时候是put进RpcContext中的attachment的副本，并未put进RpcContext的任何属性中。
综上所述，通过上述对源码的分析也解释了疑问二和疑问三，解释了dubbo3中的RpcContext.getContext().getAttachments()和invocation.getAttachments()有什么区别和为什么dubbo3中brave.dubbo.TracingFilter继续用RpcContext.getContext().getAttachments()是不行的。

总结分析

总的来说，主要是dubbo3的RpcContext被拆分为四大模块才导致brave的dubbo扩展不能直接用，但是其实改动起来还是比较简单的。上述如果有说的不对的地方，还请各位大佬指正。下面笔者还画了一张图来帮助理解：
在这里插入图片描述
最后，版权归作者所有,任何形式转载请联系作者，谢谢！

您可能感兴趣的与本文相关的镜像

ACE-Step

ACE-Step

音乐合成
ACE-Step

ACE-Step是由中国团队阶跃星辰（StepFun）与ACE Studio联手打造的开源音乐生成模型。 它拥有3.5B参数量，支持快速高质量生成、强可控性和易于拓展的特点。 最厉害的是，它可以生成多种语言的歌曲，包括但不限于中文、英文、日文等19种语言

Hey_JC
关注
Java实习模拟面试之Trace体系：分布式链路追踪原理与实战解析
吾为热爱计科，致力于知识分享的践行者，此博客是我在这条道路上留下的足迹。
08-10 1095
在微服务架构大行其道的今天，一个用户请求往往需要经过数十个甚至上百个服务的协同处理。当系统出现性能瓶颈或错误时，传统的日志排查方式如同“大海捞针”，效率极低。Trace体系（分布式链路追踪系统）应运而生，它像一张“全景地图”，清晰地描绘出请求在复杂服务网络中的完整流转路径、耗时和依赖关系。对于Java后端开发实习生而言，理解Trace体系的原理和应用，是迈向高阶开发的重要一步。本篇博客通过一场深度模拟面试。
SpringCloudZipkin链路跟踪系统
AI天才研究院
07-30 1209
Spring Cloud是一个非常流行的微服务框架，它提供了很多的组件可以帮助开发者快速构建分布式应用，包括配置中心、服务发现等。在实际生产环境中，由于各个服务之间的调用关系复杂，需要对服务之间的数据流进行监控，以便定位问题和优化系统性能。Spring Cloud Sleuth组件就是基于Apache Skywalking、Zipkin等开源项目实现了基于Spring Cloud的分布式链路跟踪功能。本文将会详细介绍一下Spring Cloud Zipkin链路跟踪系统。
【dubbo3.x trace组件分享】
qq_29154241的博客
03-21 1159
dubbo-trace基于dubbo3.x实现了traceId，spanId链路传递，使用非常简单，代码0侵入，maven直接引入即可。并且解决了子线程trace信息丢失的问题，后续会继续集成更多实用的功能
dubbo项目traceId链路传递（MDC方案及重复traceId处理）
sinat_30228861的博客
08-31 2164
dubbo项目，traceId链路传递，MDC方案，重复traceId处理
traceId怎么通过Dubbo调用传递
最新发布
青鱼入云的博客
10-23 359
需分别实现消费端和服务端的过滤器（可合并为一个类，通过判断角色区分处理）。/*** Dubbo链路追踪过滤器，自动传递traceId*/@Activate(group = {CommonConstants.CONSUMER, CommonConstants.PROVIDER}) // 激活消费端和服务端// traceId在attachment中的键名@Override// 区分消费端和服务端逻辑// 消费端：将当前MDC的traceId放入attachment。
全链路内容分享(五)：Skywalking实现Dubbo微服务链路追踪
之乎者也·的博客
02-11 1938
前面我给大家分享了关于分布式链路追踪的基本原理和的k8s部署玩法，如果还没来得及看的朋友可以看我上两篇文章。今天要给大家分享是我们日常工作中最常见的一种场景，那就是部署在k8s环境下的，要接入的具体玩法，通过这个过程咱们可以更深入的理解进行数据采集的逻辑，也能更深刻地从运维角度理解日常工作中所写的Java微服务被无侵入的方式接入分布式链路追踪系统的过程！
springboot 统一日志 链路跟踪 dubbo3链路 springboot log-starter 设计和实现- 统一dubbo3链路和log-starter管理、设计和实现
北巷东东的专栏
06-30 1124
springboot 统一日志 链路跟踪 dubbo3链路 springboot log-starter 设计和实现- 统一dubbo3链路和log-starter管理、设计和实现
dubbo分布式系统链路追踪_zipkin
weixin_33737774的博客
03-09 126
基础知识储备 分布式跟踪的目标 一个分布式系统由若干分布式服务构成，每一个请求会经过多个业务系统并留下足迹，但是这些分散的数据对于问题排查，或是流程优化都很有限，要能做到追踪每个请求的完整链路调用，收集链路调用上每个服务的性能数据，计算性能数据和比对性能指标（SLA），甚至能够再反馈到服务治理中，那么这...
sleuth+zipkin+dubbo之traceid传递处理
因为低调所以牛逼
10-20 4226
花了近一周时间 来优化traceid传递的代码，先说下之前的思路： 方案一 ： 创建一个trace 基类，设置traceid属性，用来被供业务请求vo实体来继承传参traceid，这样可以简单粗暴的解决traceid传递的问题。 缺点：显而易见，这种方式代码侵入性问题太严重，如果我有几千个vo，那岂不是要继承几千次，不现实。 方案二： 也是dubbo官网提供的一个方案，dubbo过滤器。附上官网地址：http://dubbo.apache.org/en-us/docs/dev/impls/filt
SpringCloud第七章(链路追踪Micrometer+Zipkin) -2024
huyiju的博客
09-27 1332
组件多，并且一般多是多节点集群方式部署，用户的请求量还大，想要排查一个请求的错误，无异于大海捞针，因此啊，我们就需要一种技术来帮助我们将请求给串起来，这样在出现问题之后就可以拔出萝卜带出泥的定位到没有节点的请求日志，从而轻而易举的定位到问题所在，做到有则时的改之。肯定需要定位这个请求，需要一个全局的id，在A->B->C->D的日志中，都能追踪的到这一条请求。我们可以先想一下在微服务中，一个请求从A调用B，B调用C，C调用D，然后逐次返回，怎么实现链路跟踪？1：在80、91、92中都导入依赖的jar。
SpringCloudAlibaba篇（七）SpringCloud整合Zipkin分布式链路跟踪系统（SpringCloud+dubbo+Zipkin）
weixin_43627706的博客
05-05 1406
上一篇，SpringCloudAlibaba篇（六）整合Seata（微服务分布式事务nacos+seata） 文章目录前言1、 zipkin下载安装1.1、zipkin下载1.2、zipkin建表语句1.3、zipkin启动2、zipkin整合SpringCloud2.1、添加依赖2.2、修改配置文件2.3、dubbo配置修改2.4、测试 前言 zipkin官网 Zipkin是一个分布式跟踪系统。它有助于收集解决服务体系结构中的延迟问题所需的计时数据。功能包括此数据的收集和查找。 如果日志文件中有跟踪 ID
dubbo分布式应用日志追踪
09-11
基于dubbo分布式应用集群，日志跟踪变得比以往困难。基于spi的调用拦截，可以将traceid通过rpc context保存下来，并通过MDC输出到日志中去，解决调用跟踪难的问题。
Dubbo分布式日志链路追踪
m0_67400973的博客
08-14 1373
就职于甜橙金融信息技术部,负责服务端开发，专注于微服务、分布式、性能调优、高可用，欢迎各位同仁沟通交流。
Dubbo链路追踪——生成全局ID（traceId）
web15085599741的博客
08-16 2649
我们一般的做法是在系统调用开始时生成一个traceId ， 并且它伴随着一次调用的整个生命周期。我们通过分析源码可以知道客户端在调用服务段进行服务消费时，实际上发送的是封装过的Request实体 ，Data为Invocation实体对象(接口签名，参数类型，参数值，及attachment附件)所以我们需要在调用的起始位置添加traceId信息。关于链路追踪，在微服务的趋势下，一次调用的日志信息分布在不同的机器上或目录下，当需要看一条链路调用所有的日志信息时，这是个比较困难的地方，我们虽然有。...
dubbo服务链路跟踪
燕少江湖
09-06 2085
目前很多业务使用微服务架构，服务模块划分有这2种方式： 服务功能划分 业务划分 不管哪种方式，一次接口调用都需要多个服务协同完成，其中一个服务出现问题，都会导致最终失败，虽然有logback + kafka + ELK 这样的神器架构，但是定位问题也很麻烦，如果在整个链路中，可以通过一个唯一ID（traceId）跟踪本次服务调用，就可以在ELK中查找当前traceId来定位问题。 一、案例 ...
springboot 统一日志 链路跟踪 dubbo3链路 springboot log-starter 设计和实现- 统一日志和链路跟踪 管理、设计和实现
北巷东东的专栏
06-29 762
springboot 统一日志 链路跟踪 dubbo3链路 springboot log-starter 设计和实现- 统一日志和链路跟踪 管理、设计和实现
dubbo分布式服务实现日志链路追踪traceid
weixin_43965937的博客
01-15 2072
dubbo服务日志链路追踪
Dubbo日志链路追踪TraceId选型
竹林幽深
09-28 1648
原创zlt2000陶陶技术笔记昨天 收录于话题 #微服务 14个 点击上方“陶陶技术笔记”关注我 回复“资料”获取作者整理的大量学习资料！ 链路追踪ID 一、目的 开发排查系统问题用得最多的手段就是查看系统日志，但是在分布式环境下使用日志定位问题还是比较麻烦，需要借助全链路追踪ID把上下文串联起来，本文主要分享基于Spring Boot+Dubbo框架下日志链路追踪ID的实现方案选型思路。 目前大多数分布式追踪系统的思想模型都来自 Google's Dap...
Dubbo + Sleuth + Zipkin 链路追踪
oJueQiang123456的博客
10-26 956
一、简介 1、默认情况下，Spring Cloud Sleuth支持服务之间http请求的traceId的传递。如最为常见的Feign和RestTemplate等。不支持服务在dubbo调用之间传递，所以我们要扩展dubbo的Filter。 2、使用brave-instrumentation-dubbo-rpc组件来扩展dubbo的Fiter。 二、Zipkin安装 1、下载：zipkin-server-2.12.9-exec.jar 2、启动：start.sh，访问地址：http://local
dubbo3 + shenyu 如何实现分布式链路追踪
08-28
<think>我们被要求使用Dubbo3和Shenyu实现分布式链路追踪。分布式链路追踪是微服务架构中用于跟踪请求在多个服务间流转的过程，帮助我们定位问题、分析性能。 在Dubbo3中，我们可以通过集成Micrometer或者OpenTelemetry等来实现链路追踪数据的生成和导出。而Shenyu作为API网关，同样需要支持链路追踪，并将网关接收到的请求与下游服务（如Dubbo服务）的追踪信息关联起来。 常见的做法是使用OpenTelemetry标准，因为Dubbo3和Shenyu都支持OpenTelemetry。 步骤大概如下： 1. **在Dubbo3服务中集成OpenTelemetry** - 添加相关依赖（如`dubbo-spring-boot-starter`和`opentelemetry-api`，`opentelemetry-sdk`，`opentelemetry-exporter-otlp`等） - 配置OpenTelemetry的导出器（将追踪数据导出到Jaeger、Zipkin或OTLP后端等） - 配置Dubbo的Tracing Filter，以生成和传播追踪上下文。 2. **在Shenyu网关中集成OpenTelemetry** - Shenyu支持多种插件，其中就包括OpenTelemetry插件。我们需要在Shenyu中配置OpenTelemetry，使其能够接收传入的追踪上下文（或生成新的上下文），并将上下文传播到下游的Dubbo服务。 3. **配置追踪信息的传播** - 确保在Dubbo3和Shenyu之间，追踪上下文（TraceId, SpanId等）通过Dubbo的RPC上下文正确传递。 4. **部署一个追踪后端** - 例如Jaeger、Zipkin或者SkyWalking等，用于收集、存储和展示追踪数据。 具体实现细节： ### 1. Dubbo3服务集成OpenTelemetry **添加依赖**（以Maven为例）： ```xml <!-- OpenTelemetry SDK --> <dependency> <groupId>io.opentelemetry</groupId> <artifactId>opentelemetry-sdk</artifactId> <version>1.19.0</version> </dependency> <dependency> <groupId>io.opentelemetry</groupId> <artifactId>opentelemetry-exporter-otlp</artifactId> <version>1.19.0</version> </dependency> <dependency> <groupId>io.opentelemetry</groupId> <artifactId>opentelemetry-semconv</artifactId> <version>1.19.0</version> </dependency> <!-- Dubbo Spring Boot Starter --> <dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo-spring-boot-starter</artifactId> <version>3.0.8</version> </dependency> <!-- Dubbo OpenTelemetry --> <dependency> <groupId>org.apache.dubbo.extensions</groupId> <artifactId>dubbo-opentelemetry</artifactId> <version>1.0.0</version> </dependency> ``` **配置OpenTelemetry**（在`application.properties`或`application.yml`中）： ```properties # 设置服务名 dubbo.application.name=dubbo-service-provider # 开启Tracing dubbo.tracing.enabled=true dubbo.tracing.provider=opentelemetry # OpenTelemetry Exporter配置 otel.exporter.otlp.endpoint=http://localhost:4317 otel.traces.exporter=otlp ``` **代码配置**（如果需要自定义，可以创建配置类）： ```java @Configuration public class OpenTelemetryConfig { @Bean public OpenTelemetry openTelemetry() { return OpenTelemetrySdk.builder() .setTracerProvider( SdkTracerProvider.builder() .addSpanProcessor(BatchSpanProcessor.builder(OtlpGrpcSpanExporter.builder().setEndpoint("http://localhost:4317").build()).build()) .build()) .setPropagators(ContextPropagators.create(W3CTraceContextPropagator.getInstance())) .buildAndRegisterGlobal(); } } ``` ### 2. Shenyu网关集成OpenTelemetry Shenyu使用`Apache Shenyu`插件机制，我们可以使用其`opentelemetry`插件。 **添加依赖**（在Shenyu网关项目中）： ```xml <dependency> <groupId>org.apache.shenyu</groupId> <artifactId>shenyu-spring-boot-starter-plugin-opentelemetry</artifactId> <version>2.5.0</version> </dependency> ``` **配置**（在`application.yml`中）： ```yaml shenyu: plugins: tracing: enabled: true openTelemetry: endpoint: http://localhost:4317 ``` 这样，Shenyu就会将追踪数据导出到同一个OpenTelemetry收集器（或后端）。 ### 3. 验证追踪信息 启动Jaeger或Zipkin等后端，然后通过Shenyu网关访问Dubbo服务，查看追踪数据是否完整。 ### 注意事项 - 确保所有服务（包括Shenyu网关）的时间同步，否则追踪时间线可能错乱。 - 确保追踪上下文在服务间正确传递。Dubbo3和Shenyu都会自动处理上下文传播，但需要确保它们使用相同的传播协议（如W3C Trace Context）。 - 如果使用Dubbo3的跨进程调用，需要确保调用链的连续性。 通过以上步骤，我们就可以实现基于Dubbo3和Shenyu的分布式链路追踪。 ### 引用说明 [^1]: Dubbo官方文档：https://dubbo.apache.org/zh/docs3-v2/java-sdk/features/observability/tracing/ [^2]: Shenyu官方文档：https://shenyu.apache.org/docs/plugin-center/tracing/opentelemetry §§相关问题§§ 1. 如何配置Dubbo3使用Jaeger作为追踪后端？ 2. Shenyu网关支持哪些追踪系统？ 3. 在分布式链路追踪中，如何确保上下文在不同服务间正确传递？</think>### 使用 Dubbo3 和 Shenyu 实现分布式链路追踪的方法 #### 一、核心原理 分布式链路追踪的核心是**传递上下文信息**（如 TraceID、SpanID），通过 Dubbo3 的 Filter 机制和 Shenyu 的插件体系实现全链路追踪。关键技术点： 1. **TraceID 传递**：通过 Dubbo 的 `RpcContext` 传递上下文 2. **数据采集**：使用 OpenTelemetry 标准协议 3. **数据展示**：集成 Zipkin/Jaeger 等可视化工具 #### 二、实现步骤 ##### 1. Dubbo3 服务端配置 **添加依赖**（Maven）： ```xml <!-- Dubbo 链路追踪 --> <dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo-tracing-api</artifactId> <version>3.0.8</version> </dependency> <dependency> <groupId>io.opentelemetry</groupId> <artifactId>opentelemetry-api</artifactId> <version>1.19.0</version> </dependency> ``` **配置 Tracing Filter**： ```java // 启用追踪过滤器 @Bean public Filter tracingFilter() { return new TracingFilter(); } // 注册 OpenTelemetry 导出器 @Bean public SpanExporter spanExporter() { return OtlpGrpcSpanExporter.builder() .setEndpoint("http://jaeger:4317") // 替换为实际地址 .build(); } ``` ##### 2. Shenyu 网关配置 **启用 tracing 插件**： ```yaml shenyu: plugins: tracing: enabled: true host: "localhost" port: 9411 # Zipkin 默认端口 ``` **添加请求拦截器**（传递 TraceID）： ```java public class TraceIdInterceptor implements HttpRequestInterceptor { @Override public void process(HttpRequest request) { String traceId = MDC.get("traceId"); // 从 SLF4J MDC 获取 if (traceId != null) { request.setHeader("X-B3-TraceId", traceId); } } } ``` ##### 3. 全链路追踪流程 ```mermaid sequenceDiagram Client->>Shenyu: 请求网关 (携带 TraceID) Shenyu->>DubboProvider: 转发请求 (通过 RpcContext 传递 TraceID) DubboProvider->>DubboConsumer: 内部调用 (自动传递上下文) DubboConsumer-->>Shenyu: 返回响应 Shenyu-->>Client: 返回结果 ``` #### 三、关键配置项 | 组件 | 配置项 | 示例值 | 作用 | |------------|----------------------------|-------------------------|--------------------------| | **Dubbo3** | `dubbo.provider.filter` | `tracing` | 启用追踪过滤器 | | | `otel.exporter.otlp.endpoint` | `http://jaeger:4317` | 数据导出地址 | | **Shenyu** | `shenyu.plugin.tracing.enabled` | `true` | 启用链路追踪插件 | | | `shenyu.plugin.tracing.host` | `zipkin-host` | 追踪数据存储地址 | #### 四、验证与调试 1. **日志验证**： ```shell # 查看 Dubbo 日志 grep "TraceID" dubbo.log ``` 2. **Zipkin 界面**： ```shell http://localhost:9411/zipkin # 查看完整调用链 ``` #### 五、注意事项 1. **版本兼容性**： - Dubbo3 ≥ 3.0.7 - Shenyu ≥ 2.5.0 2. **上下文传递**： - 确保跨线程时手动传递 `MDC` 上下文 3. **性能影响**： - 采样率建议设置为 0.1（10%请求采样）[^1] [^1]: 阿里巴巴微服务实践：https://developer.aliyun.com/article/781516
评论 3
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值