本文是对Zipkin官网架构介绍页面的翻译。Zipkin官网的翻译点击这里。

---

架构Architecture

架构概览

追踪器存在于应用程序内，能够记录发生操作的耗时与元数据。They often instrument libraries（它经常像Zipkin的函数库发送信息），所以它们的使用对用户是透明的。举个例子：一个装有追踪器的web server服务器会在它收到请求与发送响应的时候进行记录。被收集的数据称为Span。

Instrumentation 在编写时就考虑到应用在生产环境的安全性，并且具有很小的开销。由于这一原因，它只在in-band内传播ID以告诉接收者这里有一个追踪正在发生。完成后的Span会报告给band外的Zipkin，类似于异步的应用报告。

例如：当跟踪一个操作，并且该操作需要向外发送一个http请求时，会添加header来传播ID。header不会用于发送如操作名称这样的详细信息。

装有追踪器的APP应用中的组件可以向Zipkin发送数据，它们被称为Reporter。Reporter通过几种传送方式之一来向Zipkin的收集器collertor发送trace data追踪数据。收集器collertor会将追踪数据传给Storage。之后storage中的数据会被API查询来获取数据展示到前端UI中。

下面的图表描述了该过程：

查看是否有支持您平台的instrumentation library，请查看 existing instrumentations列表

Example flow

正如在概述中提到的，标识符ID在band内传播，而详细信息在band外传输给Zipkin。追踪器负责创建有效的追踪并正确的展现它们。例如：追踪器要确保它在band内发送的数据与band外异步发送给Zipkin的数据保持一致。

下面是一个http跟踪的示例流程，例子中用户调用 /foo 的资源。这会产生一个span，并当用户获取到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--                        │
                             └────────────────────────────────┘

跟踪器采用异步发送span数据是为了防止追踪系统发送延迟与发送失败导致用户系统的延迟与中断。

Transport

由追踪器手机的span必须从被追踪的service传送到Zipkin收集器。有三种主要的传送方式：http、Kafka以及Scribe（Facebook开源的日志收集系统）。

Components

Zipkin由4个组件构成：

• collector
• storage
• search
• web UI

Zipkin Collector

一旦追踪数据到达Zipkin collector 守护进程，会由collector 进行验证、存储以及为查询建立索引。

Storage

Zipkin创建时就会使用Cassandra （一种Nosql数据库）来存储数据，因为Cassandra 可扩展、具有灵活的schema并且被Twitter大量使用。然而，这一组件是可使用其他插件的。除了Cassandra 外，我们还支持ElasticSearch 和MySQL。其他后端可以作为第三方插件使用。

Zipkin Query Service

当数据被存储于建立索引后，我们需要一个方式来获取这些数据。查询进程提供了简单的JSON API接口来查找与获取追踪数据。这些API的主要使用者是Web UI.

Web UI

我们创建了GUI来提供界面，很好的展现追踪数据。Web UI在service、time以及annotation基础上提供了方法来查看追踪数据。需要注意的是：在UI中没有内置的认证功能。