我们都知道，微服务之间通过feign传递，在复杂的微服务架构系统中，几乎每一个前端请求都会形成一个复杂的分布式服务调用链路，在每条链路中任何一个依赖服务出现延迟超时或者错误都有可能引起整个请求最后的失败。当业务流程足够复杂时，一个完整的HTTP请求调用链一般会经过多个微服务系统，要通过日志来跟踪一整个调用链变得不再那么简单。通过sleuth可以很方便的看出每个采集请求的耗时情况，分析出哪些服务调用比较耗时，当服务调用的耗时随着请求量的增大而增大时，可以针对业务做一些优化措施。所以我们可以通过我们可以通过Spring Cloud Sleuth来解决这个问题。这里我们将演示如何通过Spring Cloud Sleuth来追踪这个过程，并借助Zipkin以图形化界面的方式展示。 展示之前，分别介绍一下rabbitmq、sleuth、zinkip。

rabbitmq

RabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件（亦称面向消息的中间件）。RabbitMQ服务器是用Erlang语言编写的，而群集和故障转移是构建在开放电信平台框架上的。所有主要的编程语言均有与代理接口通讯的客户端库。
sleuth和zinkip

sleuth 是spring cloud的组成部分之一，为springcloud应用实现了一种分布式追踪解决方案，其兼容了zinkip,HTrace和log-based追踪
Zipkin 是一款开源的分布式实时数据追踪系统（Distributed Tracking System），基于 Google Dapper 的论文设计而来，由 Twitter公司开发贡献。其主要功能是聚集来自各个异构系统的实时监控数据，用来追踪微服务架构下的系统延时问题。Zipkin 的用户界面可以呈现一幅关联图表，以显示有多少被追踪的请求通过了每一层应用。Zipkin 以 Trace 结构表示对一次请求的追踪，又把每个 Trace 拆分为若干个有依赖关系的 Span。在微服务架构中，一次用户请求可能会由后台若干个服务负责处理，那么每个处理请求的服务就可以理解为一个 Span（可以包括 API 服务，缓存服务，数据库服务以及报表服务等）。当然这个服务也可能继续请求其他的服务，因此 Span 是一个树形结构，以体现服务之间的调用关系。Zipkin 的用户界面除了可以查看 Span 的依赖关系之外，还以瀑布图的形式显示了每个 Span 的耗时情况，可以一目了然的看到各个服务的性能状况。

接下来就开始搭建
这里cloud版本用的Greenwich.SR1，boot使用的是2.1.6

然后在浏览器中输入http://localhost:15672，默认用户名和密码都是guest，登录后可看到:

点击Admin Tab页面，新增一个用户：

用户名为febs，密码为123456，角色为管理员。新添加的用户还是No access状态，需要进一步对该用户进行授权后，方可以远程通过该用户名访问。点击该新增用户名。进入授权页面，点击Set permission按钮，进行用户授权操作。
安装好RabbitMQ后，我们开始整合Zipkin。在较低版本的Spring Cloud中，我们可以自己搭建Zipkin Server，现在我们只能使用官方搭建好的Zipkin Server，地址为：

在cmd窗口下运行下面这条命令（windows下没有curl环境的话，可以在git bash中运行这条命令），下载zipkin.jar：

curl -sSL | bash -s
如果下载速度极慢，可以复制链接到迅雷下载中下载，下载后重命名为zipkin.jar即可。

zipkin支持将追踪信息保存到MySQL数据库，所以在运行zipkin.jar之前，我们先准备好相关库表，SQL脚本地址为：

/blob/master/zipkin-storage/mysql-v1/src/main/resources/mysql.sql。
库表准备好后，运行下面这条命令启动zipkin.jar：