dubbo3.x中如何使用trace组件进行性能追踪？

本文共计1257个文字，预计阅读时间需要6分钟。

Dubbo-Trace 是一个基于 Dubbo 3.x 实现的追踪系统，支持 traceId 和 spanId 的链路传递。它设计简洁，仅需10行侵入式代码即可使用，通过 Maven 直接引入即可。后续将持续集成更多实用功能，包括目录、背景等。以下是组件介绍和设计：

一、trace-dubbo 组件介绍Dubbo-Trace 组件是 Dubbo-Trace 项目的核心，负责实现追踪功能，包括生成 traceId、spanId，以及链路信息的传递。

二、设计

1.简洁性：Dubbo-Trace 设计简洁，易于集成和使用。

2.侵入性低：仅需10行代码即可实现追踪功能，降低对现有系统的侵入。

3.Maven 引入：通过 Maven 直接引入，方便快速集成。

4.持续集成：将持续集成更多实用功能，如目录、背景等。

dubbo-trace基于dubbo3.x实现了traceId，spanId链路传递，使用非常简单，代码0侵入，maven直接引入即可,后续会持续在这个项目上集成更多实用的功能

目录

• 背景
• 一、trace-dubbo组件介绍
• 二、设计原理
  • 2.1 原理图
  • 2.2 实现方案
    • 2.2.1 consumer端实现
    • 2.2.2 provider端实现
    • 2.2.3 traceId和spanId生成算法
    • 2.2.4 ThreadLocal局限性
• 三、使用步骤
  • 3.1.clone项目
  • 3.2.打包
  • 3.3.maven工程引入依赖
  • 3.4.日志输出配置
  • 3.5.服务入口调用初始化方法
• 总结

---

背景

在微服务系统里服务非常的分散，服务日志也分散在各处，多个服务没有统一并且唯一的检索条件，导致问题排查难度很大，因此trace链路追踪技术就应运而生。

---

一、trace-dubbo组件介绍

github：github.com/zbrave429/dubbo-trace
dubbo-trace基于dubbo3.x实现了traceId，spanId链路传递，使用非常简单，代码0侵入，maven直接引入即可

二、设计原理 2.1 原理图

官方文档：dubbo.apache.org/zh/docs/v3.0/references/features/attachment/

从图中可以看到，左边为consumer，右边为provider
在consumer端filter里面setAttachment 放入trace参数，在provider端filter里面getAttachment获取trace参数，执行后续处理。
原理已经很清楚了，接下来就是干

2.2 实现方案

• 请求入口将trace信息缓存到ThreadLocal内和Log参数
• consumer在发起dubbo调用时从ThreadLocal内获取trace信息设置到Attachment参数内
• provider接收到请求后从Attachment获取到trace信息缓存到ThreadLocal和Log内

2.2.1 consumer端实现

// CommonConstants.CONSUMER 客户端过滤器 @Activate(group = {CommonConstants.CONSUMER}) public class TraceConsumerFilter implements Filter { @Override public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException { // 1.从ThreadLocal内获取trace信息 Tracer tracer = TraceContext.get(); if (!Objects.isNull(tracer)){ // 2.trace信息设置到Attachment内 setTrace(invocation, tracer); } // 3.执行调用 return invoker.invoke(invocation); } } 2.2.2 provider端实现

// CommonConstants.PROVIDER @Activate(group = {CommonConstants.PROVIDER}) public class TraceProviderFilter implements Filter { @Override public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException { // 1.获取attachments参数 Map<String, String> attachments = invocation.getAttachments(); // 2.构建trace信息 Tracer tracer = buildTracer(attachments); try{ // 3.将trace信息存到ThreadLocal内和Log参数内 initTraceContext(tracer); // 4.执行业务 return invoker.invoke(invocation); } finally { // 5.清除trace信息，防止线程污染 removeTraceContext(); } } } 2.2.3 traceId和spanId生成算法

不在本篇文章讨论范围，感兴趣可以自行clone代码
git clone github.com/zbrave429/dubbo-trace.git

2.2.4 ThreadLocal局限性

理想状态下trace信息应该在一次请求的所有执行线程内进行传递，但是ThreadLocal无法在子线程内传递，因此java引入了InheritableThreadLocal ，InheritableThreadLocal可以解决主线程创建子线程时，子线程获取缓存数据的场景。但是目前更多的是使用线程池，线程池一般在服务启动时初始化，就导致通过线程池执行异步操作trace信息丢失的问题。
为了彻底解决这个问题我们可以引入阿里的线程池组件transmittable-thread-local，dubbo-trace组件已经集成，原理和使用大家可以自行百度
或参考 github.com/zbrave429/async-task

<dependency> <groupId>com.alibaba</groupId> <artifactId>transmittable-thread-local</artifactId> <version>2.12.4</version> </dependency> 三、使用步骤 3.1.clone项目

git clone github.com/zbrave429/dubbo-trace.git

3.2.打包

maven install

3.3.maven工程引入依赖

<dependency> <groupId>com.brave</groupId> <artifactId>dubbo-trace</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> 3.4.日志输出配置

日志输出格式内增加配置 %X{traceId} %X{spanId}

• %X{traceId}：traceId参数
• %X{spanId}：spanId参数，调用树

3.5.服务入口调用初始化方法

/** * IdGenEnum idGenEnum id生成器类型，目前支持两种 * UUID - 通过UUID生成的lang整形19位带符号数字 * CURRENT_TIME - 通过（时间戳11位 + 自增ID4位 + 随机数4位）生成的19位字符串 * * prefix 前缀，拼接在系统内置的算法生成的字符串之前，CURRENT_TIME模式下才有效， * 用来增强traceId的唯一性，例如：prefix = IP + APPKEY */ TraceContext.init(IdGenEnum idGenEnum, String prefix); 总结

希望本篇文章能对大家有所帮助，后续会持续在这个项目上集成更多实用的功能，例如：压测标记传递，泳道测试环境，线上测试链路，打点监控等。github上点个star，多多支持！