1. zipkin介绍
随着业务越来越复杂，系统也随之进行各种拆分，特别是随着微服务架构和容器技术的兴起，看似简单的一个应用，后台可能有几十个甚至几百个服务在支撑；一个前端的请求可能需要多次的服务调用最后才能完成；当请求变慢或者不可用时，我们无法得知是哪个后台服务引起的，这时就需要解决如何快速定位服务故障点，Zipkin分布式跟踪系统就能很好的解决这样的问题。
Zipkin分布式跟踪系统；它可以帮助收集时间数据，解决在microservice架构下的延迟问题；它管理这些数据的收集和查找；Zipkin的设计是基于谷歌的Google Dapper论文。
每个应用程序向Zipkin报告定时数据，Zipkin UI呈现了一个依赖图表来展示多少跟踪请求经过了每个应用程序；如果想解决延迟问题，可以过滤或者排序所有的跟踪请求，并且可以查看每个跟踪请求占总跟踪时间的百分比。
2.下载和启动
下载和安装

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



Transport
　　　由测试库发送的数据(Spans)必须从追踪到Zipkin的collectors的服务中传输。有三种主要的传输方式:HTTP、Kafka和Scribe。
　　Components　　

collector
storage
search
web UI

　　Zipkin Collector
　　　　一旦跟踪数据到达了Zipkin Collector守护程序，就会被Zipkin的收集器进行验证、存储和索引。
　　Storage
　　　　Zipkin最初是为了存储Zipkin的数据而建立的，因为Cassandra是可扩展的，有一个灵活的模式，在Twitter上被大量使用。但是，我们使这个组件可插拔。除了Cassandra之外，我们还支持弹性搜索和MySQL。其他的后端可以作为第三方扩展来提供。
　Zipkin Query Service
　　　　一旦数据被存储和索引，我们就需要一种方法来提取数据。查询守护进程提供一个简单的JSON API用于查找和检索跟踪。这个API的主要使用者是Web UI。
　Web UI
　　　　我们创建了一个GUI，为查看跟踪提供了一个很好的界面。web UI提供了一种基于服务、时间和注释查看跟踪的方法。注意:UI中没有内置的身份验证机制！

看一看。