zipkin，kafka,elasticsearch整合及其原理流程

大家好，我是瓜哥:

  最近公司打算启用springcloud做微服务架构，微服务开发中链路跟踪是很重要的一环，springcloud中zipkin就实现了链路跟踪的整个功能，zipkin整合中使用到了kafka做链路数据收集，elasticsearch做数据存储和搜索，下面是整个调用过程。

Zipkin 是一款开源的分布式实时数据追踪系统（Distributed Tracking System），基于 Google Dapper 的论文设计而来，由 Twitter公司开发贡献。其主要功能是聚集来自各个异构系统的实时监控数据，用来追踪微服务架构下的系统延时问题。应用系统需要进行装备（instrument）以向 Zipkin 报告数据。Zipkin 的用户界面可以呈现一幅关联图表，以显示有多少被追踪的请求通过了每一层应用。Zipkin 以 Trace 结构表示对一次请求的追踪，又把每个 Trace 拆分为若干个有依赖关系的 Span。在微服务架构中，一次用户请求可能会由后台若干个服务负责处理，那么每个处理请求的服务就可以理解为一个 Span（可以包括 API 服务，缓存服务，数据库服务以及报表服务等）。当然这个服务也可能继续请求其他的服务，因此 Span 是一个树形结构，以体现服务之间的调用关系。Zipkin 的用户界面除了可以查看 Span 的依赖关系之外，还以瀑布图的形式显示了每个 Span 的耗时情况，可以一目了然的看到各个服务的性能状况。打开每个 Span，还有更详细的数据以键值对的形式呈现，而且这些数据可以在装备应用的时候自行添加。

 可以看到zipkin内部主要分为四部分：collector、storage、api、ui

            collector：负责将各系统报告过来的追踪数据进行接收

            storage：默认使用Cassandra存储数据，也可以替换为其他存储，例如mysql5.6-5.7，ElasticSearch 2.x和5.x，还有一些第三方的存储

            api：查询服务用来向其他服务提供数据查询的能力，是以json api格式提供

            ui：Web服务是官方默认提供的一个图形用户界面