谁能用1500字就把Dapper与分布式的跟踪原理给讲明白？

Dapper与分布式跟踪原理

追根溯源，最早的分布式调用链跟踪系统——Dapper是由Google设计的。目前业界对调用链技术的实现也都是参考Dapper实现的，可以说Dapper已成为分布式调用链技术的业界标准。

Dapper的调用跟踪模型描述了分布式Tracing的基本原理和工作机制。

我们来看下核心的概念和术语。

• Trace：一次完整的分布式调用跟踪链路。

• Span：跨服务的一次调用，多个Span组合成一次Trace记录。

• Annotation：用来记录请求特定事件的相关信息（例如时间）。

下图是Dapper在调用链监控系统中描述的从用户发出请求到后端服务返回响应的整个流程。

左图可以理解为调用链经常发生的一个场景，描述了一个完整的调用链发生过程，整个链路是与5台服务器相关的一个服务，包括前端（A）、两个中间层（B和C），以及两个后端（D和E）。当一个用户（这个用例的发起人）发起一个请求时，首先到达前端，然后发送两个RPC到B和C。B会马上做出反应，但是C需要与后端的D和E交互之后再返给A，由A来响应最初的请求。

右图描述的是如何通过TraceID、Span等元素说明一个完整的链路跟踪过程。在Dapper的跟踪树结构中，树节点是这个Trace的基本单元，每个节点都是对Span的引用，节点之间的连线描述的是父子Span之间的直连关系。Dapper记录了Span名称，以及每个Span的ID和父ID，以重建在一次追踪过程中不同Span之间的关系。如果一个Span没有父ID，则被称为Root Span。所有Span都挂在一个特定的跟踪上，也共用一个跟踪ID。所有这些ID用全局唯一的64位整数标识。在一个典型的Dapper跟踪中，我们希望每一个RPC对应一个单一的Span，而且每一个额外的组件层都对应一个跟踪树型结构的层级。

从右图可见，一次请求只有一个唯一的TraceID=12345。在一次请求中，会在网络的开始生成一个全局唯一的用于标识此次请求的TraceID，这个TraceID在这次请求调用过程中无论经过多少个节点都会保持不变，最终可以通过TraceID将这一次用户请求在系统中的路径全部串起来。在这个请求的调用链中，SpanA调用了SpanB，然后SpanB调用了SpanC和SpanD，每一次Span调用都会生成一个自己的Span ID，并且记录自己的上级Span ID是谁。可以通过Span ID来定位当前请求在整个系统调用链中的位置，以及它的上下游节点，通过这些SpanID，整个链路基本上就都能标识出来了。

Dapper 允 许 应 用 在 跟 踪 过 程 中 添 加 额 外 信 息 ， 以 表 征 这 个Annotation是用来即时记录事件的发生信息的，以下是一系列预定义的用来记录一次请求开始和结束的核心Annotation。

• Client Start（CS）：客户端发起一次请求时的记录。

• Server Receive（SR）：服务器收到请求并开始处理，SR和CS的差值就是网络延时和时钟的误差。

• Server Send（SS）：服务器完成处理并返回客户端，SS和SR的差值就是实际处理时长。

• Client Receive（CR）：客户端收到回复时建立，标志着一个Span的结束。我们通常认为，一旦CR被记录了，一个RPC调用也就完成了。

常用的分布式调用链技术

目前市面上很多APM工具都基于Dapper论文，下面简单介绍在业界影响比较广泛的调用链跟踪技术。

• CAT：大众点评开源的基于手动代码埋点和配置的集调用链分析、应用监控、日志采集、监控报警于一体的监控平台工具。

• Zipkin：Twitter开源的调用链分析工具，可以与SpringCloud Sleuth结合使用，部署简单，使用轻量。

• SkyWalking：国内开源的一款APM工具，基于字节码注入方式，接入端代码无侵入实现，支持多种插件，UI功能比较强大，目前已经进入Apache孵化器。

本文给大家讲解的内容是服务监控治理，服务调用链技术，Dapper与分布式跟踪原理

1. 下篇文章给大家讲解的内容是服务监控治理，服务调用链技术，Sleuth与Zipkin技术
2. 觉得文章不错的朋友可以转发此文关注小编；
3. 感谢大家的支持！