分布式链路追踪理论

基本概念

分布式调用链标准-openTracing

Span-节点组成跟踪树结构

有一些特定的变量，SpanName SpanId traceId spanParentId

Trace（追踪）：代表一个完整的请求流程（如用户下单），由多个Span组成

Span（跨度）：请求经过的单个服务或操作（如订单服务调用支付服务）

包含：开始/结束时间、服务名、调用关系等

Context（上下文）：传递Trace ID、Span ID等，确保链路连续

分布式链路追踪 = Trace ID串联全局 + Span记录局部 + 上下文传递

Span节点必须包含的内容

OperationName：操作名称

BeiginTime：开始时间

EndTime：结束时间

SpanTag：是一组键值对构成的Span的标签集合（key必须是String类型，value可以是String，Boolean和数字类型），这个的目的是为Span添加更多的描述信息

SpanLog：一组Span的日志集合，是键值对，记录日志信息

SpanContext：是一个上下文对象，会从上一个节点传递到下一个节点，里面包含了traceId，SpanId，Baggage（这是一个跨Span集合，上一个节点往Baggage加信息下一个节点可以拿到，不要放太多信息不然会导致占用空间大影响效率）,我们通过上下文对象去进行跨进程传递

TraceSegment和TraceId原理

TraceSegment：

指的是一个进程中所有的Span的集合
如果多个线程协同产生同一个Trace（例如多个RPC调用不同的方法），它们只会共同创建一个TraceSegment
支持多入口，所以Skywalking去除了树节点RootSpan的概念，提出了三种Span模型

TraceId：

TraceId应该是全局唯一的
我们的TraceId是根据时间错+算法生成的，所以会有时间回拨问题
我们有个变量lastTimeStamp保存上次TraceId生成的时间，然后在生成TraceId前进行比较，如果CuurentTimeMills比lastTimeStamp时间小，说明时间回拨了，我们就不生成Id，这样来保证TraceId全局唯一

概念简单总结

三个基本概念：Trace追踪，Span服务，Context上下文（用来传递信息）

分布式链路追踪 = Trace ID串联全局 + Span记录局部 + 上下文传递

Span中包含starTime，endTime，SpanContetx（上下文用来传递信息，包含TraceId，SpanId），

SpanTag（服务的标签）,SpanLog（服务的日志信息）

TraceSegment（追踪段）：一个进程中所有的Span的集合

TraceId：全局唯一，依赖时间戳，保存上次TraceId生成的时间，生成ID时时间戳进行对比，防止时间回拨问题

全链路追踪的工作流

阶段1：链路数据生成（埋点）

自动埋点：通过SDK或Agent自动在服务框架（如Spring Cloud、Dubbo）中注入追踪逻辑。

手动埋点：在业务代码中手动标记关键操作（如支付流程）。

示例：用户下单时，网关生成Trace ID=ABC，创建根Span（Span ID=1）

阶段2：链路数据采集与传输

采集方式：通过Agent或Sidecar（如Envoy）实时收集Span数据。

传输协议：通过gRPC、HTTP等将数据发送到Collector（如Jaeger Collector）。

示例：订单服务（Span ID=2）和库存服务（Span ID=3）的Span通过Kafka发送到收集器。

阶段3：链路数据存储

存储后端：使用时序数据库（如InfluxDB）、列式存储（如Cassandra）或Elasticsearch。

数据模型：按Trace ID聚合Span，建立索引（如服务名、耗时、错误码）。

示例：Trace ID=ABC的所有Span被存储为一条完整链路。

阶段4：数据查询与分析

可视化：通过UI工具（如Zipkin、SkyWalking）展示火焰图、调用拓扑。

分析能力：支持按服务名、耗时、错误码过滤，自动统计P99延迟、错误率。

示例：发现库存服务（Span ID=3）平均耗时500ms，触发告警

流程简单总结

链路数据生成：在进入Span服务前生成数据，一般来说再进入服务器会有自定义数据处理or服务启动前的Agent增强让服务有了多余的自定义逻辑
实时采集与传输链路数据：通过Http或者grpc采集和传输链路追踪的数据
链路数据存储：存储链路追踪的数据
数据查询与分析可视化：通过可视化页面展示详细的链路追踪流程和数据，显示服务细节，耗时，错误等