zipkin学习--01--理论

zipkin学习–01–理论

---

一、zipkin介绍

1. 是分布式跟踪系统（Distributed Tracking System）

   1. 监控微服务各个服务的调用情况
   2. 举例:一个请求A，需要先后调用f1,f2,f3等微服务单元的接口，我们可以通过链路追踪查看f1,f2,f3对应接口的耗时。

2. 主要功能

   1. 聚集来自各个异构系统的实时监控数据。
   2. 追踪微服务架构下的系统延时问题

3. 分布式跟踪系统其他比较成熟的实现

   1. Naver的Pinpoint
   2. Apache的HTrace
   3. 阿里的鹰眼Tracing
   4. 京东的Hydra
   5. 新浪的Watchman
   6. 美团点评的CAT，skywalking等。

4. 应用系统需要进行装备（instrument）以向 Zipkin 报告数据

5. Zipkin 的用户界面

   1. 可以呈现一幅关联图表，以显示有多少被追踪的请求通过了每一层应用。
   2. 可以查看 Span 的依赖关系
   3. 可以以瀑布图的形式显示了每个 Span 的耗时情况，可以一目了然的看到各个服务的性能状况。
      1. 打开每个 Span，还有更详细的数据以键值对的形式呈现，而且这些数据可以在装备应用的时候自行添加。

6. Zipkin 以 Trace 结构表示对一次请求的追踪，又把每个 Trace 拆分为若干个有依赖关系的 Span。

   1. 在微服务架构中，一次用户请求可能会由后台若干个服务负责处理，那么每个处理请求的服务就可以理解为一个 Span（可以包括 API 服务，缓存服务，数据库服务以及报表服务等）。当然这个服务也可能继续请求其他的服务，因此 Span 是一个树形结构，以体现服务之间的调用关系。

7. 背景

   微服务架构上通过业务来划分服务的，通过REST调用，对外暴露的一个接口，这个接口功能可能需要很多个服务协同，如果链路上任何一个服务出现问题，都会导致接口调用失败。
   随着业务的不断扩张，服务之间互相调用越复杂。调用链的分析也会越复杂

   zipkin主要就是可以跟踪接口调用情况，提供数据分析

二、架构图

1. 跟踪器(Tracer)位于你的应用程序中，并记录发生的操作的时间和元数据,提供了相应的类库，对用户的使用来说是透明的，收集的跟踪数据称为Span;将数据发送到Zipkin的仪器化应用程序中的组件称为Reporter,Reporter通过几种传输方式之一将追踪数据发送到Zipkin收集器(collector)，然后将跟踪数据进行存储(storage),由API查询存储以向UI提供数据。

2. ZipKin可以分为两部分:zipkin server和zipkin client

2.1、客户端和服务器

zipkin server：用来作为数据的采集存储、数据分析与展示

1. Collector

   1. 收集器组件，它主要用于处理从外部系统发送过来的跟踪信息，将这些信息转换为Zipkin内部处理的Span格式，以支持后续的存储，分析，展示等功能。

2. Storage

   1. 存储接受或收集过来的数据
   2. 当前支持Memory，MySQL，Cassandra，ElasticSearch等
   3. 默认存储在内存中。

3. API（Query）

   1. 负责查询Storage中存储的数据，提供简单的JSON API获取数据，主要提供给web UI使用

4. Web UI

   1. UI组件，基于API组件实现的上层应用。
   2. 通过UI组件用户可以方便而有直观地查询和分析跟踪信息。

zipkin client：完成追踪数据的生成与上报功能

2.2、概念和字段说明

1. Trace

   1. Zipkin使用Trace结构表示对一次请求的跟踪

      1. 一次请求可能由后台的若干服务负责处理

         1. 每个服务的处理是一个Span，Span之间有依赖关系

   2. Trace就是树结构的Span集合

2. 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
          }
        }
      ]
    }
   

3. transport

   1. 负责从运输从service收集来的spans，并把这些spans转化为zipkin的通用span，并将其传递到存储层，这种方法是模块化的，允许任何生产者接收任何类型的数据
   2. zipkin配有HTTP、kafka、scribe三种类型的transport
   3. 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框架拦截，然后

1. 把当前调用链的Trace信息添加到HTTP Header里面
2. 记录当前调用的时间戳
3. 发送HTTP请求，把trace相关的header信息携带上
4. 调用结束之后，记录当前调用花费的时间
5. 然后把上面流程产生的 信息汇集成一个span，把这个span信息上传到zipkin的Collector模块

四、 核心数据结构

4.1、traceId

1. 标记一次请求的跟踪，相关的Spans都有相同的traceId
2. Zipkin将具有相同traceId的span组装成跟踪树来直观的将调用链路图展现在我们面前。

4.2、id

span的id

4.3、parentId

当前Span的父Span id，通过parentId来保证Span之间的依赖关系，如果没有parentId，表示当前Span为根Span；

4.4、name

1. span的名称，一般是接口方法的名称
2. name的作用是让人知道它是哪里采集的span

4.5、timestamp

Span创建时的时间戳。单位是微秒，可能服务器有时钟偏差导致时间错误

4.6、duration

1. 持续时间，即span的创建到span完成最终的采集所经历的时间，除去span自己逻辑处理的时间
2. 该时间段可以理解成对于该跟踪埋点来说服务调用的总耗时

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地址、返回码和异常信息等），可以将需要的数据以键值对的形式放入到这个字段中。