Zipkin介绍和使用

Zipkin是一个分布式链路跟踪系统，可以采集时序数据来协助定位延迟等相关问题。数据可以存储在cassandra,MySQL,ES,mem中。分布式链路跟踪是个老话题，国内也有类似的框架，比如阿里的skywalking。 zipkin目前和SpringCloud生态结合紧密，有相关的支持。

主要包括客户端和一个管理服务端。在客户端采集数据后，发送给服务端，用来展示数据。在每个instrumented的客户端，写入了traceId，然后统一收集数据在服务端存储。这里instrumented翻译过来是仪器化，设备化，为了简单我把他称作 标识实体 ，代表一个接入了zipkin的客户端。

zipkin包括四个组件，collector，storage，search，webUI。其中collector中重点有两个

zipkin可以跟踪多种请求，如async方法,schedule,rxjava等，都在 org.springframework.cloud.sleuth.instrument 包下，这里以web请求做介绍。在SpringCloud下用sleuth来做跟踪处理。具体通过一个拦截器 org.springframework.cloud.sleuth.instrument.web.TraceHandlerInterceptor 实现，如下

zipkin支持mem，MySQL，ES存储方式，以 io.zipkin.java:zipkin-server:2.6.1 为例，可以通过配置实现。具体配置项可以在 zipkin-server-shared.yaml 中查看，如下：

同时，举例用MySQL作为存储时的一张span对象表，如下：

一般来说，分布式的链路跟踪数据是比较大量的，建议采用ES来存储，方便支持分区，以及后期的扩展等，比如使用某些字段来存储非结构化数据。

以上就是所有内容，下面是一个请求和记录展示。

随着现在系统的逐步分布式化、规模化、微服务的流行，系统之间的调用越来越复杂，那么有一个自上而下的追踪系统就尤为重要了，我们可以快速定位到系统的瓶颈并作出相应的调整。

zipkin 是一款开源的分布式实时数据追踪系统（Distributed Tracking System），基于 Google Dapper 的论文设计而来，由 Twitter 公司开发贡献。其主要功能是聚集来自各个异构系统的实时监控数据，用来追踪微服务架构下的系统延时问题。（国内开源的还有美团点评的cat、京东的hydra）

github： https://github.com/openzipkin/zipkin

Quick Start

如果按照上文的获取官网jar包方式启动了zipkin-server，那么client启动之后，服务调用的请求就会以http请求的方式打到zipkin-server端，数据存在内存中，server重启之后丢失。上面的配置都增加了rabbitmq，作为中间件，zipkin-server也按照相应的配置来通过rabbitmq接收消息。

如果想定制zipkin-server的服务，比如作为服务发现节点、动态配置参数，那么可以自定义一个zipkin-server

加入eureka（服务发现）、sleuth、rabbit（消息中间件）、mysql（驱动包）、zipkin包（或者使用zipkin-autoconfigure-ui+spring-cloud-sleuth-zipkin-stream，不过我当时使用这两包有报错，所以替换掉了）

按照上面的配置搞定之后，分别启动rabbitmq、server、client，先调用几次服务，然后查看zipkin的web站 http://localhost:9411/

http://blog.spring-cloud.io/blog/sc-sleuth.html

http://spring-cloud.io/reference/sleuth/#_3

http://cloud.spring.io/spring-cloud-static/spring-cloud-sleuth/1.0.9.RELEASE/

sleuth也不是一个新鲜的东西，说白了就是一个APM的一个浓缩版，spring Cloud Sleuth为 spring Cloud提供了分布式跟踪的解决方案，它大量借用了Google Dapper、 Twitter Zipkin和 Apache HTrace的设计

构建了ELK的日志系统和监控系统这两个能够快速的发现系统中的问题，但是由于微服务架构中系统众多，系统之间的交互还比较复杂，在产生了大量的日志之后，可以帮助我们定位问题，但是在紧急情况下难以帮助我们快速，是快速的定位和解决问题，这个就调用链的设计初衷，在微服务中，调用链比较长的时候，如果出现问题，很容易出现踢皮球的情况，这种情况下，打开调用链，一看，谁的就是谁的不说不闹，多好。

市面上比较常见的APM有：pinpoint,Twitter的zipkin,美团的Cat，Google的Dapper，这里值得表扬美团，继续和金服的pk吧，最牛的还是Google，他发表了一篇Dapper就有好多公司去研究，最终形成自己的产品，不由的让我想起他的GFS，bigTable在大数据前期google为大数据所做的贡献，向慷慨的人致敬，懂得分享的人最可爱，嗯，对···进入正题

简单说一下调用链的东西TraceID 链路ID 在整个调用链中这个东西是不变的

SpanId 步骤ID 经过一个node就会变

ParentSpanID 很同意理解，这个spanId是从哪个span来的，这个设计很重要的

复杂的东西spring boot已经给我们封装好了

#######sleuth客户端

在需要跟踪的微服务中pom.xml加上

在application.yml中添加

pom.xml添加

并且在启动类上添加

客户端和服务端都启动，进入到zipkin服务端

可以根据时间，服务名称去查询，点击可查看调用链详情

因为现在zipkin的调用数据都是存在内存中的，一旦zipkin server重启，则意味着之前的都没有了，在这并发高的，一会就把内存挤爆了，所以最终zipkin的数据是要持久化的，要么mysql，这里采用ES,毕竟在大数据检索面前ES比mysql好很多很多

还有在页面请求量大的时候zipkin和ES直接联通存数据，肯定会阻塞，这里就用kafka来解决这个问题

pom.xml需要引入

application.yml添加

再次启动，加入数据，观察ES-head

已经将调用链存进去了，这里要感谢spring 将调用链集成，方便我们应用

望指正，不吝赐教

---