zipkin学习–01–理论
一、zipkin介绍
- 是分布式跟踪系统（Distributed Tracking System）
- 监控微服务各个服务的调用情况
- 举例:一个请求A，需要先后调用f1,f2,f3等微服务单元的接口，我们可以通过链路追踪查看f1,f2,f3对应接口的耗时。
- 主要功能
- 聚集来自各个异构系统的实时监控数据。
- 追踪微服务架构下的系统延时问题
- 分布式跟踪系统其他比较成熟的实现
- Naver的Pinpoint
- Apache的HTrace
- 阿里的鹰眼Tracing
- 京东的Hydra
- 新浪的Watchman
- 美团点评的CAT，skywalking等。
- 应用系统需要进行装备（instrument）以向 Zipkin 报告数据
- Zipkin 的用户界面
- 可以呈现一幅关联图表，以显示有多少被追踪的请求通过了每一层应用。
- 可以查看 Span 的依赖关系
- 可以以瀑布图的形式显示了每个 Span 的耗时情况，可以一目了然的看到各个服务的性能状况。
- 打开每个 Span，还有更详细的数据以键值对的形式呈现，而且这些数据可以在装备应用的时候自行添加。
- Zipkin 以 Trace 结构表示对一次请求的追踪，又把每个 Trace 拆分为若干个有依赖关系的 Span。
- 在微服务架构中，一次用户请求可能会由后台若干个服务负责处理，那么每个处理请求的服务就可以理解为一个 Span（可以包括 API 服务，缓存服务，数据库服务以及报表服务等）。当然这个服务也可能继续请求其他的服务，因此 Span 是一个树形结构，以体现服务之间的调用关系。
- 背景
微服务架构上通过业务来划分服务的，通过REST调用，对外暴露的一个接口，这个接口功能可能需要很多个服务协同，如果链路上任何一个服务出现问题，都会导致接口调用失败。
随着业务的不断扩张，服务之间互相调用越复杂。调用链的分析也会越复杂
zipkin主要就是可以跟踪接口调用情况，提供数据分析
二、架构图
- 跟踪器(Tracer)位于你的应用程序中，并记录发生的操作的时间和元数据,提供了相应的类库，对用户的使用来说是透明的，收集的跟踪数据称为Span;将数据发送到Zipkin的仪器化应用程序中的组件称为Reporter,Reporter通过几种传输方式之一将追踪数据发送到Zipkin收集器(collector)，然后将跟踪数据进行存储(storage),由API查询存储以向UI提供数据。
- ZipKin可以分为两部分:zipkin server和zipkin client
2.1、客户端和服务器
zipkin server：用来作为数据的采集存储、数据分析与展示
- Collector
- 收集器组件，它主要用于处理从外部系统发送过来的跟踪信息，将这些信息转换为Zipkin内部处理的Span格式，以支持后续的存储，分析，展示等功能。
- Storage
- 存储接受或收集过来的数据
- 当前支持Memory，MySQL，Cassandra，ElasticSearch等
- 默认存储在内存中。
- API（Query）
- 负责查询Storage中存储的数据，提供简单的JSON API获取数据，主要提供给web UI使用
- Web UI
- UI组件，基于API组件实现的上层应用。
- 通过UI组件用户可以方便而有直观地查询和分析跟踪信息。
zipkin client：完成追踪数据的生成与上报功能
2.2、概念和字段说明
- Trace
- Zipkin使用Trace结构表示对一次请求的跟踪
- 一次请求可能由后台的若干服务负责处理
- 每个服务的处理是一个Span，Span之间有依赖关系
- Trace就是树结构的Span集合
- Span
每个服务的处理跟踪是一个Span，可以理解为一个基本的工作单元，如下：
//一个Span
{
//标记一次请求的跟踪，相关的Spans都有相同的traceId
"traceId": "bd7a977555f6b982",
//span的名称，一般是接口方法的名称
"name": "get-traces",
//span id
"id": "ebf33e1a81dc6f71",
//当前Span的父Span id，通过parentId来保证Span之间的依赖关系，如果没有parentId，表示当前Span为根Span；
"parentId": "bd7a977555f6b982",
//Span创建时的时间戳。单位是微秒，可能服务器有时钟偏差导致时间错误
"timestamp": 1458702548478000,
//持续时间,单位是微秒
"duration": 354374,
//注解用于及时记录事件；有一组核心注解用于定义RPC请求的开始和结束
"annotations": [
{
"endpoint": {
"serviceName": "zipkin-query",
"ipv4": "192.168.1.2",
"port": 9411
},
"timestamp": 1458702548786000,
"value": "cs"
}
],
//二进制注释，旨在提供有关RPC的额外信息。
"binaryAnnotations": [
{
"key": "lc",
"value": "JDBCSpanStore",
"endpoint": {
"serviceName": "zipkin-query",
"ipv4": "192.168.1.2",
"port": 9411
}
}
]
}- transport
- 负责从运输从service收集来的spans，并把这些spans转化为zipkin的通用span，并将其传递到存储层，这种方法是模块化的，允许任何生产者接收任何类型的数据
- zipkin配有HTTP、kafka、scribe三种类型的transport
- instrumentations负责和transport进行交互。
三、 服务追踪流程如下：
┌─────────────┐ ┌───────────────────────┐ ┌─────────────┐ ┌──────────────────┐
│ User Code │ │ Trace Instrumentation │ │ Http Client │ │ Zipkin Collector │
└─────────────┘ └───────────────────────┘ └─────────────┘ └──────────────────┘
│ │ │ │
┌─────────┐
│ ──┤GET /foo ├─▶ │ ────┐ │ │
└─────────┘ │ record tags
│ │ ◀───┘ │ │
────┐
│ │ │ add trace headers │ │
◀───┘
│ │ ────┐ │ │
│ record timestamp
│ │ ◀───┘ │ │
┌─────────────────┐
│ │ ──┤GET /foo ├─▶ │ │
│X-B3-TraceId: aa │ ────┐
│ │ │X-B3-SpanId: 6b │ │ │ │
└─────────────────┘ │ invoke
│ │ │ │ request │
│
│ │ │ │ │
┌────────┐ ◀───┘
│ │ ◀─────┤200 OK ├─────── │ │
────┐ └────────┘
│ │ │ record duration │ │
┌────────┐ ◀───┘
│ ◀──┤200 OK ├── │ │ │
└────────┘ ┌────────────────────────────────┐
│ │ ──┤ asynchronously report span ├────▶ │
│ │
│{ │
│ "traceId": "aa", │
│ "id": "6b", │
│ "name": "get", │
│ "timestamp": 1483945573944000,│
│ "duration": 386000, │
│ "annotations": [ │
│--snip-- │
└────────────────────────────────┘简单说明
一个应用的代码发起HTTP get请求，经过Trace框架拦截，然后
- 把当前调用链的Trace信息添加到HTTP Header里面
- 记录当前调用的时间戳
- 发送HTTP请求，把trace相关的header信息携带上
- 调用结束之后，记录当前调用花费的时间
- 然后把上面流程产生的 信息汇集成一个span，把这个span信息上传到zipkin的Collector模块
四、 核心数据结构
4.1、traceId
- 标记一次请求的跟踪，相关的Spans都有相同的traceId
- Zipkin将具有相同traceId的span组装成跟踪树来直观的将调用链路图展现在我们面前。
4.2、id
span的id
4.3、parentId
当前Span的父Span id，通过parentId来保证Span之间的依赖关系，如果没有parentId，表示当前Span为根Span；
4.4、name
- span的名称，一般是接口方法的名称
- name的作用是让人知道它是哪里采集的span
4.5、timestamp
Span创建时的时间戳。单位是微秒，可能服务器有时钟偏差导致时间错误
4.6、duration
- 持续时间，即span的创建到span完成最终的采集所经历的时间，除去span自己逻辑处理的时间
- 该时间段可以理解成对于该跟踪埋点来说服务调用的总耗时
4.7、annotations
用于定位一个request的开始和结束，cs/sr/ss/cr含有额外的信息，比如说时间点，当这个annotation被记录了，这个RPC也被认为完成了。
4.7.1、cs: Client Start
表示客户端发起请求,一个span的开始
4.7.2、cr：Client Received
表示客户端获取到服务端返回信息，一个span的结束
4.7.3、sr：Server Receive
表示服务端收到请求
4.7.4、ss：Server Send
表示服务端完成处理，并将结果发送给客户端
4.7.5、sr-cs：sr的时间-cs的时间
网络延迟
4.7.6、ss-sr：ss的时间-sr的时间
逻辑处理时间
4.7.7、cr-cs：cr的时间-cs的时间
整个流程时间
4.8、binaryAnnotations
业务标注列表，如果某些跟踪埋点需要带上部分业务数据（比如url地址、返回码和异常信息等），可以将需要的数据以键值对的形式放入到这个字段中。
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
