一、Zipkin的由来
在单机系统使用过程中，如果某个请求响应过慢或者响应出错，通过查看日志就可以清楚的知道某个请求出了问题；如果在分布式系统中，客户端一个请求到达服务器后，由多个服务协作完成。如服务A调用服务B，服务B调用服务C，服务C调用服务D，那么想要知道哪个服务处理时间过长或是处理异常导致的话，就需要一个服务一个服务的去机器查看日志，先定位出问题的服务，再定位出问题的地方。随着系统越来越壮大，服务越来越多，一个请求对应处理的服务调用链就越长，这种排查方式很艰难，为了解决这个问题，便诞生了各种分布式场景中追踪问题的解决方案，zipkin就是其中之一。
二、什么是ZipKin
一个独立的分布式追踪系统，客户端存在于应用中（各个服务中），应具备追踪信息生成，采集发送等功能，而服务端应该包含以下基本的三个功能
1）信息收集：用来收集各服务端采集的信息，并对这些信息进行梳理存储、建立索引
2）数据存储：存储追踪数据
3）查询服务：提供查询请求链路信息的接口
三、 它的整体结构图
Zipkin（服务端）包含四个组件，分别是collector，storage，search，Web UI
1）collector信息收集器，作为一个守护进程，它会时刻等待着客户端传递过来的追踪数据，对这些数据进程验证，存储以及创建查询需要的索引
2）storage是存储组件，zipkin默认直接将数据存储在内存中，此外支持使用Cassandra、Elasticsearch和Mysql
3）search是一个查询进程，它提供了简单的JSON API来提供外部调用查询
4）Web UI是zipkin的服务端展示平台，主要调用search提供的接口，用图标将链路信息清晰的展示
四、基本概念
Trace：一个请求达到应用后所调用的所有服务组成的调用链就像一个树结构（如图），我们追踪这个调用链路得到的这个数结构可以称之为Trace
Span：在一次Trace中，每个服务的每一次调用，就是一个基本工作单元（如图中的每一个树节点），称之为span
每一个span都有一个id作为唯一标识，同样每一次Trace都会生成一个traceID在span中作为追踪评标识，另外再通过一个parentId标明本次调用的发起者（就是发起者的span-id）。当span有了上面三个标识后，就可以很清晰的将多个span进行梳理串联，最终归纳出一条完整的跟踪链路。