Zipkin的Span模型

zipkin 加上监控的功能+ 通过 tracid 将如虎添翼. 稳定性监控和定位都搞定了.

本文将详细介绍Zipkin的Span模型，以及其他“另类”Span模型的设计。

          这里多一句嘴，其实专业点的叫法应该是分布式追踪系统——Distributed TracingSystem，跟踪比较适合用于人的场景，比如某人被跟踪了，而追踪更适合用于计算机领域。然并卵？本文将继续使用“跟踪”。

        Zipkin的Span模型几乎完全仿造了Dapper中Span模型的设计，我们知道，Span用来描述一次RPC调用，所以一个RPC调用只应该关联一个spanId（不算父spanId），Zipkin中的Span主要包含三个数据部分：

• 基础数据：用于跟踪树中节点的关联和界面展示，包括traceId、spanId、parentId、name、timestamp和duration，其中parentId为null的Span将成为跟踪树的根节点来展示，当然它也是调用链的起点，为了节省一次spanId的创建开销，让顶级Span变得更明显，顶级Span中spanId将会和traceId相同。timestamp用于记录调用的起始时间，而duration表示此次调用的总耗时，所以timestamp+duration将表示成调用的结束时间，而duration在跟踪树中将表示成该Span的时间条的长度。需要注意的是，这里的name用于在跟踪树节点的时间条上展示。
• Annotation数据：用来记录关键事件，只有四种，cs（Client Send）、sr（Server Receive）、ss（Server Send）、cr（Client Receive），所以在Span模型中，Annotation是一个列表，长度最多为4。每种关键事件包含value、timestamp和endpoint，value就是cs、sr、ss和cr中的一种，timestamp表示发生的时间，endpoint用于记录发生的机器（ip）和服务名称（serviceName）。可以很自然的想到，cs和cr、sr和ss的机器名称是相同的，为了简单起见，cs和cr的服务名称可以一样，sr和ss的服务名称可以一样。Annotation数据主要用于用户点击一个Span节点时展示具体的Span信息。
• BinaryAnnotation数据：我们并不满足在跟踪树上只展示调用链的时间信息，如果需要绑定一些业务数据（日志）的话，可以将数据写入BinaryAnnotation中，它的结构和Annotation数据一模一样，在Span中也是一个列表，这里就不再阐述，但BinaryAnnotation中不宜放太多数据，不然将导致性能和体验的下降。

1.

2.

3.

这两个图的区别是 图1 spandId 代表着一次夸度调用.,Zipkin的设计那样，需要传递traceId、spanId还有parentSpanId

图2 spanId 代表着 服务器节点 id.   都调用 server2,server3的 spanId 和 parentId都相同,无法区分.

图3 spanId 同图2, 但是没有了 parentId, 多了个 childSpandId. childSpanId由父亲节点生成并传递给子节点.只需要传递 cspandId.

[1]  分布式跟踪系统（二）：Zipkin的Span模型