一、前提：组件组成
- trace: 一个完整的链路由 多个segment组成
- segment: 一个请求在一个进程内的轨迹片段
- span:一个请求在某个进程里的一个组件\逻辑内的轨迹片段
trace 对 segment : 1 对 n
segment 对 span : 1 对 n
1. 基本组件图示
image.png
image.png
2. 组件关联关系
从上图中可以看出，两种关系：
- trace关系
1.1 一个trace内的所有span的traceid是相同的 - ref 关联关系
2.1 后一个segment的Entryspan总是与前一个segment中的某个ExitSpan关联：
2.2 后一个segment中的处理的请求源自前一个segment；
2.3 ref关系满足请求的一出一入原则；对Segment来说是一入多（0..n）出原则 - parent关系
3.1 通常一个Segment中有一个EntrySpan,是Segment内其他span的 根parent.
3.2 segment内的span是树状组织关系
3.3 新Segment内EntrySpan的parentSpanId 是上游Segment对应ExitSpan的spanId
二、Trace的数据协议
1. Trace数据协议格式
Trace数据协议格式参考Trace Data Protocol v3，其中有grpc 和 http两个维度的介绍，这里从http的视角解读注意事项，首先两个关键协议格式：
1.1 其中http格式的协议参考：HTTP 1.1
1.2 跨进程传播头部协议参考：SkyWalking Cross Process Propagation Headers Protocol
2. 数据关联
对于EntrySpan来说，如果其对应上游Segment的某个ExitSpan,那么需要留意ref中字段与对应的ExitSpan之间的数据关系，而ExitSpan的数据则有跨进程传播头部协议承载（下表格中用Header表示）
ExitSpan -> 跨进程传播头部协议(Header) -> EntrySpan-ref
| ref类型 | ref名称 | 对应Header值 | 备注 |
|---|---|---|---|
| RefType | refType | CrossProcess 、CrossThread | Header中的值是0/1，0：跨线程，1：跨进程 |
| String | traceId | traceId | |
| String | parentTraceSegmentId | parentTraceSegmentId | |
| int | parentSpanId | SpanId，即上游Segment对应ExitSpan的SpanId | |
| String | parentService | parentService | |
| String | parentServiceInstance | parentServiceInstance | |
| String | parentEndpoint | endpoint | |
| String | networkAddressUsedAtPeer | peer |
3. Trace的数据协议特殊字段说明
按照官方链接仔细阅读，基本都没问题，这边只列举几个容易争议的
- EntrySpan 没有peer
- ExitSpan 必须有peer
- 没有上游Segment的EntrySpan，parentSpanId = -1,有上游Segment的EntrySpan,其parentSpanId 是其对应的ExitSpan的spanId
- traceId 不是链路中首个Segment的SegmentId，而是其后又生成的一个Id
附语
对skywalking架构设计、性能调优感兴趣可以查看作者的文章：
如果这些内容对您有所帮助，或者有所启发的话，可以关注公众号：「架构染色」，进行交流和学习。
