关键词文章采集源码(Spring陈某介绍一下CloudSleuth和zipkin这两个组件为主，后续文章介绍)

　　关键词文章采集源码(Spring陈某介绍一下CloudSleuth和zipkin这两个组件为主，后续文章介绍)

　　今天的文章文章陈介绍链接跟踪相关的知识，主要是Spring Cloud Sleuth和zipkin这两个组件，后续文章再介绍一个。

　　文章的目录如下：

　　

　　为什么需要链接跟踪？

　　在大型分布式微服务系统中，一个系统被划分为N个多个模块，负责不同的功能，组合成一套系统，最终可以提供丰富的功能。在这种分布式架构中，一个请求往往需要涉及多个服务，如下图所示：

　　

　　服务之间的调用复杂，维护成本成倍增加。难免会出现以下问题：

　　为了快速定位分布式架构中的问题，分布式链路追踪应运而生。将分布式请求还原到调用链接，执行日志记录、性能监控，并集中显示分布式请求的调用。比如每个服务节点花费的时间，请求到达哪台机器，每个服务节点的请求状态等等。

　　常见的链接跟踪技术有哪些？

　　市面上有很多链接跟踪项目，其中也有一些非常优秀的，如下：

　　什么是 Spring Cloud Sleuth？

　　Spring Cloud Sleuth 实现了分布式服务链接跟踪解决方案。通过使用 Sleuth，我们可以快速定位服务的问题。简单来说，Sleuth 相当于调用链监控工具的客户端，与各个微服务集成在一起，负责生成调用链监控数据。

　　"

　　Spring Cloud Sleuth 只负责生成监控数据，通过日志展示，不提供可视化的 UI 界面。

　　"

　　在学习 Sleuth 之前，有几个概念是必须要了解的：

　　Spring Cloud 是如何集成 Sleuth 的？

　　集成 Spring Cloud Sleuth 其实并不难。在此之前，您需要准备以下三项服务：

　　三个服务的调用关系如下：

　　

　　客户端请求网关发起订单查询请求，网关路由到订单服务，订单服务获取订单明细，调用商品服务获取商品明细。

　　添加依赖项

　　在父模块中添加sleuth依赖如下：

　　

org.springframework.cloud

spring-cloud-starter-sleuth

　　以上只是Spring Cloud Sleuth的依赖，Nacos和openFeign的依赖这里不再详述。不清楚的可以用陈老师之前的文章文章和案例源码来补漏。

　　调整日志级别

　　由于 sleuth 没有 UI 界面，所以需要调整日志级别才能在控制台中看到更详细的链接信息。

　　将以下配置添加到三个服务的配置文件中：

　　## 设置openFeign和sleuth的日志级别为debug，方便查看日志信息

logging:

level:

org.springframework.cloud.openfeign: debug

org.springframework.cloud.sleuth: debug

　　完善的演示界面

　　下面的界面只是为了演示创建的数据，并没有集成DB。

　　sleuth-order9033 查询订单详情的接口，如下图：

　　

　　sleuth-product9032产品详情查询界面如下：

　　

　　gateway-sleuth9031网关路由配置如下：

　　

　　测试

　　启动以上三个服务，浏览器可以直接访问：:9031/order/get/12

　　观察控制台日志输出，如下图：

　　

　　日志格式共有四个参数，含义如下：

　　好吧，既然整合完成了，我不禁深吸一口气，直接看日志，不是瞎了眼……

　　"

　　案例源码已上传，公众号【码猿科技专栏】回复关键词9528获取。

　　"

　　什么是 ZipKin？

　　Zipkin 是 Twitter 的一个开源项目。它基于 Google Dapper。它专门用于采集服务的时序数据。

　　为了解决微服务架构中的延迟问题，包括数据的采集、存储、搜索和呈现。

　　ZipKin 的基础架构如下：

　　

　　Zipkin分为4个核心组件，如下：

　　zipkin 分为服务器和客户端。服务器主要用于采集跟踪数据并显示。客户端的主要功能是将其发送到服务器。微服务的应用也是客户端。一旦调用发生，*敏*感*词*器就会被触发，将 sleuth 日志数据传输到服务器。

　　如何搭建zipkin服务器？

　　首先需要下载服务器的jar包，地址：

　　下载完成后会得到一个jar包，如下图：

　　

　　直接启动jar，命令如下：

　　java -jar zipkin-server-2.23.4-exec.jar

　　出现如下界面表示启动完成：

　　

　　这时候就可以访问zipkin的UI界面了，地址：9411，界面如下：

　　

　　以上是通过下载jar来搭建服务器。当然还有其他的安装方式，比如docker，自己试试吧，陈不再演示了。

　　如何构建 zipKin 客户端？

　　服务器只跟踪数据的采集和显示，而客户端是数据的生成和传输者。下面详细介绍如何构建客户端。

　　或者上面例子中的三个微服务，直接添加zipkin的依赖，如下：

　　

org.springframework.cloud

spring-cloud-starter-zipkin

　　注意：由于spring-cloud-starter-zipkin中已经收录了Spring Cloud Sleuth依赖，所以只需要引入上述依赖之一即可。

　　配置文件需要配置zipkin服务器的地址，配置如下：

　　spring:

cloud:

sleuth:

sampler:

# 日志数据采样百分比，默认0.1(10%)，这里为了测试设置成了100%，生产环境只需要0.1即可

probability: 1.0

zipkin:

#zipkin server的请求地址

base-url: http://127.0.0.1:9411

#让nacos把它当成一个URL，而不要当做服务名

discovery-client-enabled: false

　　以上配置完成后，就可以启动服务了。此时访问：:9031/order/get/12

　　调用界面后，再次访问zipkin的UI界面，如下图：

　　

　　可以看到刚才调用的接口已经被*敏*感*词*了，点击SHOW进入详情视图，如下图：

　　

　　可以看到左侧显示了一个完整的链接，包括服务名称、耗时，右侧显示了服务调用的信息，包括开始、结束时间、请求url、请求方法……

　　除了调用链接的信息外，还可以清晰的看到各个服务的依赖关系，如下图所示：

　　

　　如何切换zipKin的数据传输模式？

　　zipkin默认的传输方式是HTTP，但是这里有个问题。一旦在传输过程中客户端和服务器断开连接，跟踪日志信息就会丢失。

　　当然，zipkin也支持MQ传输，支持消息中间件如下：

　　使用MQ传输不仅可以保证消息丢失的问题，还可以提高传输效率。生产环境中推荐使用 MQ 传输。

　　那么问题来了，怎么切换呢？

　　其实方法很简单。让 Chen 以 RabbitMQ 为例进行介绍。

　　1、服务器连接到 RabbitMQ

　　运行服务器并使用以下命令连接到 RabbitMQ：

　　java -jar zipkin-server-2.23.4-exec.jar --zipkin.collector.rabbitmq.addresses=localhost --zipkin.collector.rabbitmq.username=guest --zipkin.collector.rabbitmq.password=guest

　　命令分析如下：

　　2、客户端添加RabbitMQ

　　由于使用了MQ传输，所以必须添加相应的依赖和配置。添加RabbitMQ依赖如下：

　　

org.springframework.boot

spring-boot-starter-amqp

　　配置MQ的地址、用户名、密码如下：

　　spring:

rabbitmq:

addresses: 127.0.0.1

username: guest

password: guest

　　3、配置文件中的传输模式切换

　　配置 spring.cloud.zipkin.sender.type 用于切换传输方式。rabbit的值表示使用rabbitMQ进行数据传输。

　　配置如下：

　　spring:

cloud:

zipkin:

sender:

## 使用rabbitMQ进行数据传输

type: rabbit

　　注意：使用MQ传输时，可以去掉spring.cloud.zipkin.sender.base-url。

　　完整的配置如下：

　　

　　4、测试

　　由于使用了MQ传输，我们可以在不启动服务器的情况下成功传输。浏览器访问：:9031/order/get/12

　　这时候发现服务没有报异常。看到在RabbitMQ中已经传输了数据，并且存在于zipkin队列中，如下图：

　　

　　可以看到有消息没有被消费。点击查看消息内容为 Trace 和 Span 相关信息。

　　好的，我们启动服务器，命令如下：

　　java -jar zipkin-server-2.23.4-exec.jar --zipkin.collector.rabbitmq.addresses=localhost --zipkin.collector.rabbitmq.username=guest --zipkin.collector.rabbitmq.password=guest

　　服务端启动后，发现zipkin队列中的消息瞬间被消费。查看zipkin的UI界面，发现已经生成了链接信息，如下图：

　　

　　zipkin 是如何持续存在的？

　　zipkin的信息默认存储在内存中。一旦服务器重启，信息就会丢失，但 zipkin 提供了可插拔存储。

　　zipkin 支持以下四种存储方式：

　　今天Chen会以MySQL为例介绍zipkin是如何持久化的，Elasticsearch会放在下一篇文章中，有点长。

　　1、创建数据库

　　zipkin服务器上的MySQL建表SQL在源码中的zipkin-storage/mysql-v1/src/main/resources/mysql.sql中。我将把这个SQL文件放在案例源代码中。

　　"

　　github地址：

　　"

　　创建的数据库：zipkin（任意名称），导入SQL进行建表，新创建的数据库表如下：

　　

　　2、服务器配置 MySQL

　　服务器配置很简单，运行以下命令：

　　java -jar zipkin-server-2.23.4-exec.jar --STORAGE_TYPE=mysql --MYSQL_HOST=127.0.0.1 --MYSQL_TCP_PORT=3306 --MYSQL_DB=zipkin --MYSQL_USER=root --MYSQL_PASS=Nov2014

　　以上命令参数分析如下：

　　陈是如何记住这些参数的？废话，记不住了，你可以随时查看源代码。这些配置在源码的配置文件/zipkin-server/src/main/resources/zipkin-server-shared.yml中，比如上面提到的MySQL配置，如下图：

　　

　　zipkin服务器的所有配置项都在这里，我没什么可看的。

　　"

　　github地址：

　　"

　　然后使用rabbitMQ传输方式和MySQL持久化方式，完整命令如下：

　　java -jar zipkin-server-2.23.4-exec.jar --STORAGE_TYPE=mysql --MYSQL_HOST=127.0.0.1 --MYSQL_TCP_PORT=3306 --MYSQL_DB=zipkin --MYSQL_USER=root --MYSQL_PASS=Nov2014 --zipkin.collector.rabbitmq.addresses=localhost --zipkin.collector.rabbitmq.username=guest --zipkin.collector.rabbitmq.password=guest

　　持久化是服务端做的，和客户端无关，所以结束了陈就不再测试了，自己试试吧。

　　总结

　　前面介绍了这么多。不知道你有没有仔细读过。让我们总结一下：

　　zipkin 默认以内存的形式存储。MySQL也是一种方法，但是随着数据量的增加，性能下降。因此，建议在生产环境中使用 Elasticsearch。下一篇文章会介绍。