zipkin架构

zipkin

Zipkin是一个分布式追踪系统。它有助于收集解决微服务架构中延迟问题所需的时序数据。它管理这些数据的收集和查找。Zipkin的设计基于 Google Dapper论文。

image

架构概述

追踪器驻留在你的应用程序里，并且记录发生操作的时间和元数据。他们经常装配在库上，所以对用户来说是透明的。举个例子，一个装配过的 Web 服务器，会在接收请求和发送响应进行记录。收集的追踪数据叫做 Span（跨度）。

生产环境中的装配器应该是安全并且低负载的。为此，带内（in-band）只传输 ID，并且告诉接收器仍有一个追踪在处理。完成的跨度在带外（out-of-band）汇报给 Zipkin，类似于应用程序异步汇报指标一样。

举个例子，当追踪一个操作的时候，该操作对外发送了一个 HTTP 请求，那么，为了传输 ID 就会添加一些额外的头部信息。头部信息并不是用于发送像是操作明这样的详细信息的。

装配应用中用于向 Zipkin 发送数据的组件叫做 Reporter。Reporter 通过 Transport 发送追踪数据到 Zipkin 的 Collector，Collector 持久化数据到 Storage 中。之后，API 从 Storage 中查询数据提供给 UI。

下面的图表描述了整个流程：

image

示例流程

正如概述中所提到的，标识符是在带内发送的，细节以带外形式发送到Zipkin。在这两种情况下，跟踪工具都负责创建有效的痕迹并正确渲染它们。例如，跟踪器可确保它在带内（下游）和带外（向Zipkin异步）发送的数据之间进行平衡。

以下是用户代码调用资源/ foo的http跟踪示例序列。这会导致一个跨度，在用户代码收到http响应后异步发送到Zipkin。

┌─────────────┐ ┌───────────────────────┐  ┌─────────────┐  ┌──────────────────┐
│ 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--                        │
                             └────────────────────────────────┘

跟踪检测报告异步跨越，以防止与跟踪系统相关的延迟或故障延迟或破坏用户代码。

Transport
装配库发送的跨度必须由装配的服务传输到 Collector。 有三种主要的传输类型：HTTP、Scribe 和 Kafka。更多信息查看跨度接收器。

共有四个组件构成了 Zipkin：

1. collector
2. storage
3. search
4. web UI

Zipkin Collector

一旦追踪数据抵达 Zipkin Collector 守护进程，Zipkin Collector 为了查询，会对其进行校验、存储和索引。

Storage

Zipkin 最初是构建在将数据存储在 Cassandra 中，因为 Cassandra 易跨站，支持灵活的 schema，并且在 Twitter 内部被大规模使用。然而，我们将这个组件做成了可插拔式的。在 Cassandra 之外，我们原生支持 ElasticSearch 和 MySQL。可作为第三方扩展提供给其它后端。

Zipkin 查询服务

一旦数据被存储索引，我们就需要一种方式提取它。查询守护进程提供了一个简单的 JSON API 查询和获取追踪数据。API 的主要消费者就是 Web UI。

Web UI

我们创建了一个用户图形界面为追踪数据提供了一个漂亮的视图。Web UI 提供了基于服务、时间和标记（annotation）查看追中数据的方法。注意：UI 没有内置的身份认证功能。