zipkin学习第一天

zipkin，开源的分布式实时追踪系统，Distributed Tracking System，聚集来自各个异构系统的实时监控数据，用来追踪微服务架构下的系统延时问题。

主要四部分： collector，storage，api，ui

  collector，负责将各个系统报告过来的追踪数据进行接收；

  storage，默认使用Cassandra（开源分布式Nosql数据库）存储数据，也可以替换为其他存储，如：mysql5.6~5.7,ElasticSearch2.x和5.x，还有一些第三方存储；

  api，查询服务用来向其他服务提供数据查询的能力，是以json api格式提供；

  ui，web服务是官方默认提供的一个图形界面。

Transport 

  负责从运输从service收集来的spans，并把这些spans转化为zipkin通用的spans，将数据传递到存储层，这种方法是模块化的，允许任何生产者接收任何类型的数据，zipkin配有HTTP、kafka、scribe三种类型的transport。

核心数据结构

  traceId：全局跟踪ID，标记一次完整服务调用，所以和一次调用相关的span和traceId都是相同的；

  id：span的id，理论上来说span的id只要做到一个traceId下唯一就可以；

  parentId：父span的id，调用层级关系，树形结构；

  timestamp：span创建时的时间戳，用来记录采集的时刻；

  duration：持续时间，即span创建到完成所经历的时间，除去span自己逻辑处理时间，该时间段可以理解成对于该跟踪埋点来说服务调用总时长

  annotation：基本标注列表，一个标注可以理解成span生命周期中重要时刻的数据快照，比如一个标注中包含发生时刻、时间类型、端点等信息；

事件类型

  cs：客户端/消费者发起请求

  cr：客户端/消费者收到应答

  sr：服务端/生产者接收到请求

  ss：服务端/生产者发送请求

   ps：这四种事件类型的统计都是zipkin提供客户端来做的，与业务事件无关。

  binaryAnnotation：业务标注列表，如果某些跟踪埋点需要带上部分业务数据（比如url、返回码和异常信息等），可以将需要的数据以键值对的形式放入到这个字段。