架构

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

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

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

你所在平台是否已经有现成的装配库，可以查看：现有的装配库。

Transport

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

• collector
• storage
• web UI

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

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

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