链路追踪 SkyWalking 源码分析 —— Collector 接收 Trace 数据

点击上方“芋道源码”，选择“设为星标”

做积极的人，而不是积极废人！

源码精品专栏

 

• 原创 | Java 2019 超神之路，很肝~
  

• 中文详细注释的开源项目
  

• RPC 框架 Dubbo 源码解析

• 网络应用框架 Netty 源码解析
  

• 消息中间件 RocketMQ 源码解析
  

• 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析

• 作业调度中间件 Elastic-Job 源码解析

• 分布式事务中间件 TCC-Transaction 源码解析

• Eureka 和 Hystrix 源码解析

• Java 并发源码

摘要: 原创出处 http://www.iocoder.cn/SkyWalking/collector-receive-trace/ 「芋道源码」欢迎转载，保留摘要，谢谢！

本文主要基于 SkyWalking 3.2.6 正式版

• 1. 概述

• 2. TraceSegmentServiceHandler

• • 2.1 TraceSegmentService

  • 2.2 SegmentParse

  • 2.3 Standardization 标准化

• 3. Buffer 文件

• • 3.1 初始化

  • 3.2 写入

  • 3.3 读取

• 666. 彩蛋

---

1. 概述

分布式链路追踪系统，链路的追踪大体流程如下：

1. Agent 收集 Trace 数据。

2. Agent 发送 Trace 数据给 Collector 。

3. Collector 接收 Trace 数据。

4. Collector 存储 Trace 数据到存储器，例如，数据库。

本文主要分享【第三部分】 SkyWalking Collector 接收 Trace 数据。

友情提示：Collector 接收到 TraceSegment 的数据，对应的类是 Protobuf 生成的。考虑到更加易读易懂，本文使用 TraceSegment 相关的原始类。

大体流程如下：

• Collector 接收到 TraceSegment 数据后，进行构建。

• 【蓝色流程】构建成功，进行流式处理，最终存储到存储器( 例如，ES / H2 )。

• 【粉色流程】构建失败，写入 Buffer 文件进行暂存。

• 【绿色流程】后台线程，定时读取 Buffer 文件，重新提交构建。

什么是构建？

从 TraceSegment 数据中，会构建出更多的数据维度，如下图所示：

构建的过程，本文只分享调用的过程，具体怎么生成新的数据，数据的流式处理与存储，在 《SkyWalking 源码解析 —— Collector 存储 Trace 数据》 详细解析。

为什么构建会失败？

在 TraceSegment 里的数据结构，例如操作名( operationName )和操作编号( operationId ) ，在 《SkyWalking 源码分析 —— Agent 收集 Trace 数据》 中我们可以看到，考虑到网络传输，优先使用 operationId ，若不存在( 例如操作还未注册，或者注册了 Agent 未同步到本地 )，则使用 operationName 。

但是，Collector 构建过程时，要求的是 operationId ，如果传递的是 operationName 时，需要将 operationName 转换成 operationId 。若此时 operationName 未注册时，则无法获取到 operationId ，导致构建失败。

那么有胖友可能有疑惑，在构建过程中，注册 operationName 呢？答案是不行， 在 《SkyWalking 源码分析 —— Agent DictionaryManager 字典管理》「2.2 操作的同步 API」 中，我们可以看到，operationName 的注册，是异步的过程。因而，即使构建的过程中，调用注册，也无法获得