10、Skywalking的埋点-Trace的基本概念

开始之前先仔细阅读skywalking创始人吴晟的一些文章资料：

opentracing文档中文版吴晟
增强高度分布式和大规模应用系统的拓扑自动检测

对skywalking架构设计、性能调优感兴趣可以查看作者的文章：

【Skywalking on the way-千亿级的数据储能、毫秒级的查询耗时】
【当月亮守护地球 | SkyWalking Agent守护你的应用...有它相伴才安逸】

TraceSegment

skywalking中关于trace的一些概念，较opentracing来说是进行了一些扩展，比如其核心TraceSegment表示一类span的聚合。
我们这样来理解：在微服务架构中，一个请求基本都会涉及跨进程（以及跨线程）的操作，例如， RPC 调用、通过 MQ 异步执行等这类操作就需要涉及到多个服务的多个线程，TraceSegment 就记录了一个请求在一个线程中的执行流程。当将该请求所关联的全部 TraceSegment串起来，就能得到该请求的完整 Trace，总结来说即是：

一个trace由多个tracesegment构成
一个Tracesegemnt记录了一个请求在一个线程中的执行流程
一个TraceSegment内包含一个Span集合

TraceSegment 的核心字段结构如下：

traceSegmentId（ID 类型）：通过GlobalIdGenerator 生成，是TraceSegment 的全局唯一标识。
ref（TraceSegmentRef类型）：它指向父 TraceSegment。在 RPC 调用、HTTP 请求等跨进程调用中，一个 TraceSegment 最多只有一个父 TraceSegment，但是在一个 Consumer 批量消费 MQ 消息时，同一批内的消息可能来自不同的 Producer，这就会导致 Consumer 线程对应的 TraceSegment 有多个父 TraceSegment了，系统只保留第一个父 TraceSegment,早期版本是保留了全部。
relatedGlobalTraceId（DistributedTraceIds 类型）：记录当前 TraceSegment 所属 Trace 的 Trace ID，批处理场景下也只保留第一个。
spans（List 类型）：当前 TraceSegment 包含的所有 Span。
ignore（boolean 类型）：ignore 字段表示当前 TraceSegment是否被忽略。主要是为了忽略一些问题 TraceSegment（据说是对只包含一个 Span 的 Trace 进行采样收集）。
isSizeLimited（boolean 类型）：每个 TraceSegment 中 Span 的个数是有上限的（默认值为 300，可动态配置），超过上限之后，就不再添加 Span了；这是一个内存保护措施。

Span

skywalking中Span分为 2大类，RemoteSpan和LocalSpan，其中RemoteSpan又分为EntrySpan和ExitSpan：

EntrySpan：当请求进入服务时，会创建 EntrySpan 类型的 Span，它也是 TraceSegment 中的第一个 Span。例如，HTTP 服务、RPC 服务、MQ-Consumer 等入口服务的插件在接收到请求时都会创建相应的 EntrySpan。
ExitSpan：当请求离开当前服务、进入其他服务时会创建 ExitSpan 类型的 Span。例如， Http Client 、RPC Client 发起远程调用或是 MQ-producer 生产消息时，都会产生该类型的 Span。
LocalSpan：它是在本地方法调用时可能创建的 Span 类型，处于EntrySpan和ExitSpan之间，应用程序中可通过@Trace 注解标注在方法上创建一个LocalSpan。

TracingContext

每个 TraceSegment 都绑定一个 TracingContext上下文对象，记录了 TraceSegment 的上下文信息。
提供的功能有：

管理 TraceSegment生命周期
创建Span 比如三个创建Span的方法#createEntrySpan、#createLocalSpan 方法、#createExitSpan
跨进程传播上下文
跨线程传播上下文

跨进程传播

ContextCarrier见名知意，是Context 的搬运工（Carrier），负责在进程之间搬运 Context的一些基本信息，将夸进程调用链连接起来。

看下其成员的作用：

traceId（String 类型）：它记录了当前 Trace ID。
traceSegmentId（ID 类型）：从 Client 端看，它记录了 Client 中 `TraceSegment ID；从 Server 端看，记录的是父 TraceSegment 的 ID。
spanId（int 类型）：从 Client 端看，它记录了当前 ExitSpan 的 ID；从 Server 端看，记录的是父 Span的 ID。
parentService：它记录的是 Client 的服务描述信息
parentServiceInstance ：它记录的是 Client 服务实例的描述信息
parentEndpoint（String 类型）：它记录了 Client 端的EndpointName
addressUsedAtClient（String 类型）：它记录了 client端请求Server 端的地址(ip:port, hostname:port) 。
extensionContext （ExtensionContext类型）：作为扩展上下文，其内包含一些可选上下文，以增强某些场景中的分析。
correlationContext （CorrelationContext类型）：作为容器，用于放置用户自定义的Context信息。

跨进程传播 Context 上下文信息的核心流程大致为：

远程调用的 Client 端会调用 inject(ContextCarrier)方法，将当前 TracingContext中记录的 Trace 上下文信息填充到传入的ContextCarrier 对象。
后续 Client 端的插件会将 ContextCarrier 对象序列化成字符串并将其作为附加信息添加到请求中，这样，ContextCarrier 字符串就会和请求一并到达 Server 端。
Server 端接收请求的插件会检查请求中是否携带了 ContextCarrier字符串，如果存在 ContextCarrier 字符串，就会将其进行反序列化，然后调用extract()方法从 ContextCarrier 对象中取出 Context 上下文信息，填充到当前 TracingContext（以及 TraceSegmentRef) 中。

对于Dubbo组件来说，其ContextCarrier 的传播过程如下图所示:

image.png

序列化之后的 ContextCarrier 字符串会利用attachments的机制放到 RpcContext 中，在服务端从attachments中取出反序列化后填充到当前TraceContext中。

跨线程转播

跨线程转播，是在同一个进程中，不同的线程之间传递，这个传递过程不需要序列化，遵循以下步骤实现：

调用ContextManager#capture 方法获取ContextSnapshot对象
把这个ContextSnapshot对象传递给子线程
在子线程中调用ContextManager#continued(ContextSnapshot snapshot)方法

最后说一句(请关注，莫错过)