从问题出发：为什么需要全链路追踪？

在得物，随着业务发展，应用从单一结构变成多个服务相互调用，形成了复杂的分布式系统。想象一下，一个用户下单买鞋，这个请求从手机App发出，会经过网关、订单服务、库存服务、支付服务、物流服务等很多环节。如果在这个过程中，订单处理变慢了，甚至出错了，工程师很难快速定位问题到底出在哪个环节。这就是分布式系统一个典型的“可观测性”挑战。过去，大家可能只能看单个服务的日志或者监控，但这些信息是孤立的，无法看到请求完整的路径和状态。

Trace2.0数据采集的核心理念：更全、更准、更轻

为了应对上述挑战，得物开发了Trace2.0系统。它致力于捕捉每一次用户请求在分布式系统中流转的完整轨迹，这个轨迹被称为一个“Trace”。每一个Trace都有一个全局唯一的ID。当请求进入系统时，如果还没有Trace ID，就会生成一个；如果已经有了（比如从上游服务传过来），就继续使用它。请求每经过一个服务，系统就会记录下这个服务节点的信息，比如开始时间、结束时间、是否出错等，这些信息被称为一个“Span”。一个Trace就是由许多个相互关联的Span组成的，像一棵树一样，清晰地展示了请求的调用链。

Trace2.0在数据采集上强调三个关键点。第一是“更全”，它希望尽可能自动地捕捉主流框架和技术组件（比如HTTP调用、数据库操作、消息队列处理等）中的调用信息，减少开发人员手动添加代码的负担。第二是“更准”，它需要精确记录关键的性能指标，比如每一步的耗时，并且要保证在请求的复杂传递过程中，上下文信息（比如Trace ID）不能丢失或出错。第三是“更轻”，因为采集行为本身不能对线上服务的性能造成太大影响，所以采集代码要高效，并且可以根据需要调整采集的“采样率”，对一些访问量巨大的请求进行抽样采集，在效果和成本之间取得平衡。

数据采集如何实现：探针、上下文传递与采样

那么，具体是如何采集到这些数据的呢？得物Trace2.0主要依靠一种叫做“探针”的技术。简单理解，就是在不修改或极少修改业务代码的情况下，通过一些技术手段（例如Java Agent字节码增强），“注入”一些采集逻辑到应用程序中。当程序执行到关键位置（比如收到网络请求、发送数据库查询）时，这些探针就会被触发，自动创建Span、记录时间、采集上下文信息。

上下文传递是另一个关键技术。一个请求从服务A调用到服务B，需要把Trace ID、当前Span ID等信息传递过去，服务B才能知道自己属于哪个调用链。这通常通过修改网络请求的HTTP头部或者RPC框架的元数据来实现。得物的系统需要确保这种传递在各种技术框架和网络协议下都能可靠工作。

最后，面对海量请求，全量采集所有数据成本太高。因此，Trace2.0会采用灵活的动态采样策略。比如，可以为重要业务接口设置较高的采样率（甚至100%采集），为一些不重要的后台任务设置很低的采样率。也可以根据请求的延迟情况来判断，如果某个请求响应特别慢，就自动提高其相关链路的采样优先级，确保问题能被捕捉到。

从采集数据到系统可观测性

采集到的Trace数据被安全地发送到后端服务器进行处理和存储。这些原始的轨迹数据本身价值有限，但经过汇总和分析后，就能产生强大的洞察力。工程师可以通过一个可视化界面，轻松查询某个特定请求的完整调用链，快速定位慢调用或错误发生在哪个服务、哪一步操作。更进一步，系统可以聚合分析这些Trace数据，生成服务依赖拓扑图，直观展示各个服务之间的调用关系和健康状态；可以统计服务的平均响应时间、错误率等指标，形成性能大盘。

这样一来，分布式系统就从“黑盒”变成了“白盒”。当出现故障时，排查时间从小时级缩短到分钟级；在系统优化时，可以精准找到性能瓶颈。可以说，以Trace2.0为代表的链路追踪系统，是构建云原生时代可观测性体系的基石，它让开发和运维人员能够真正“看清”复杂系统的内部运行状态，保障得物业务的稳定和流畅体验。所有技术实现细节和设计考量，均基于得物技术团队在官方技术博客和相关分享（如“得物技术”公众号）中披露的信息进行阐述。