java B2B2C电子商务平台分析之十三-----Spring Cloud Zipkin

Zipkin是什么
Zipkin分布式跟踪系统；它能够帮助收集时间数据，解决在microservice架构下的延迟问题；它管理这些数据的收集和查找；Zipkin的设计是基于谷歌的Google Dapper论文。愿意了解源码的朋友直接求求交流分享技术：二一四七七七五六三三

每一个应用程序向Zipkin报告定时数据，Zipkin UI呈现了一个依赖图表来展现多少跟踪请求通过了每一个应用程序；若是想解决延迟问题，能够过滤或者排序全部的跟踪请求，而且能够查看每一个跟踪请求占总跟踪时间的百分比。

为何使用Zipkin
随着业务愈来愈复杂，系统也随之进行各类拆分，特别是随着微服务架构和容器技术的兴起，看似简单的一个应用，后台可能有几十个甚至几百个服务在支撑；一个前端的请求可能须要屡次的服务调用最后才能完成；当请求变慢或者不可用时，咱们没法得知是哪一个后台服务引发的，这时就须要解决如何快速定位服务故障点，Zipkin分布式跟踪系统就能很好的解决这样的问题。

Zipkin原理

针对服务化应用全链路追踪的问题，Google发表了Dapper论文，介绍了他们如何进行服务追踪分析。其基本思路是在服务调用的请求和响应中加入ID，标明上下游请求的关系。利用这些信息，能够可视化地分析服务调用链路和服务间的依赖关系。

对应Dpper的开源实现是Zipkin，支持多种语言包括JavaScript，Python，Java, Scala, Ruby, C#, Go等。其中Java由多种不一样的库来支持

Spring Cloud Sleuth是对Zipkin的一个封装，对于Span、Trace等信息的生成、接入HTTP Request，以及向Zipkin Server发送采集信息等所有自动完成。Spring Cloud Sleuth的概念图见上图。

Zipkin架构

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

.

1.Trace
Zipkin使用Trace结构表示对一次请求的跟踪，一次请求可能由后台的若干服务负责处理，每一个服务的处理是一个Span，Span之间有依赖关系，Trace就是树结构的Span集合；

2.Span
每一个服务的处理跟踪是一个Span，能够理解为一个基本的工做单元，包含了一些描述信息：id，parentId，name，timestamp，duration，annotations等。

3.Transport
收集的Spans必须从被追踪的服务运输到Zipkin collector，有三个主要的传输方式：HTTP, Kafka和Scribe；

4.Components
有4个组件组成Zipkin：collector，storage，search，web UI
collector：一旦跟踪数据到达Zipkin collector守护进程，它将被验证，存储和索引，以供Zipkin收集器查找；
storage：Zipkin最初数据存储在Cassandra上，由于Cassandra是可扩展的，具备灵活的模式，并在Twitter中大量使用；可是这个组件可插入，除了Cassandra以外，还支持ElasticSearch和MySQL；  存储，zipkin默认的存储方式为in-memory，即不会进行持久化操做。若是想进行收集数据的持久化，能够存储数据在Cassandra，由于Cassandra是可扩展的，有一个灵活的模式，而且在Twitter中被大量使用，咱们使这个组件可插入。除了Cassandra，咱们原生支持ElasticSearch和MySQL。其余后端可能做为第三方扩展提供。
search：一旦数据被存储和索引，咱们须要一种方法来提取它。查询守护进程提供了一个简单的JSON API来查找和检索跟踪，主要给Web UI使用；
web UI：建立了一个GUI，为查看痕迹提供了一个很好的界面；Web UI提供了一种基于服务，时间和注释查看跟踪的方法。

总体代码结构以下：