大家好,我是不才陈某~
今天这篇文章陈某介绍一下链路追踪相关的知识,以Spring Cloud Sleuth和zipkin这两个组件为主,后续文章介绍另外一种。
为什么需要链路追踪?
大型分布式微服务系统中,一个系统被拆分成N多个模块,这些模块负责不同的功能,组合成一套系统,最终可以提供丰富的功能。在这种分布式架构中,一次请求往往需要涉及到多个服务
服务之间的调用错综复杂,对于维护的成本成倍增加,势必存在以下几个问题:
为了能够在分布式架构中快速定位问题,分布式链路追踪应运而生。将一次分布式请求还原成调用链路,进行日志记录,性能监控并将一次分布式请求的调用情况集中展示。比如各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态等等。
市面上有很多链路追踪的项目,其中也不乏一些优秀的,如下:
spring-cloud-sleuth
使用较为简单, 集成很方便, 但是功能较简单。
Spring Cloud Sleuth实现了一种分布式的服务链路跟踪解决方案,通过使用Sleuth可以让我们快速定位某个服务的问题。简单来说,Sleuth相当于调用链监控工具的客户端,集成在各个微服务上,负责产生调用链监控数据。
Spring Cloud Sleuth只负责产生监控数据,通过日志的方式展示出来,并没有提供可视化的UI界面。
学习Sleuth之前必须了解它的几个概念:
整合Spring Cloud Sleuth其实没什么的难的,在这之前需要准备以下三个服务:
客户端请求网关发起查询订单的请求,网关路由给订单服务,订单服务获取订单详情并且调用商品服务获取商品详情。
在父模块中添加sleuth依赖,如下:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
以上只是Spring Cloud Sleuth的依赖,还有Nacos,openFeign的依赖这里就不再详细说了,有不清楚的可以结合陈某前面几篇文章和案例源码补漏一下。
由于sleuth并没有UI界面,因此需要调整一下日志级别才能在控制台看到更加详细的链路信息。
在三个服务的配置文件中添加以下配置:
## 设置openFeign和sleuth的日志级别为debug,方便查看日志信息
logging:
level:
org.springframework.cloud.openfeign: debug
org.springframework.cloud.sleuth: debug
以下接口只是为了演示造的数据,并没有整合DB。
启动上述三个服务,浏览器直接访问:http://localhost:9031/order/get/12
观察控制台日志输出,日志格式中总共有四个参数,含义分别如下:
好了,至此整合完成了,不禁心里倒吸一口凉气,直接看日志那不是眼睛要看瞎了……….
案例源码已经上传,公众号【码猿技术专栏】回复关键词 9528获取。
Zipkin 是 Twitter 的一个开源项目,它基于Google Dapper实现,它致力于收集服务的定时数据,
以解决微服务架构中的延迟问题,包括数据的收集、存储、查找和展现。
Zipkin共分为4个核心的组件,如下:
zipkin分为服务端和客户端,服务端主要用来收集跟踪数据并且展示,客户端主要功能是发送给服务端,微服务的应用也就是客户端,这样一旦发生调用,就会触发监听器将sleuth日志数据传输给服务端。
首先需要下载服务端的jar包,地址:https://search.maven.org/artifact/io.zipkin/zipkin-server/2.23.4/jar
下载完成将会得到一个jar包
直接启动这个jar,命令如下:
java -jar zipkin-server-2.23.4-exec.jar
出现以下界面表示启动完成
此时可以访问zipkin的UI界面,地址:http://localhost:9411,界面如下:
以上是通过下载jar的方式搭建服务端,当然也有其他方式安装,比如docker,自己去尝试一下吧,陈某就不再演示了。
服务端只是跟踪数据的收集和展示,客户端才是生成和传输数据的一端,下面详细介绍一下如何搭建一个客户端。
还是上述例子的三个微服务,直接添加zipkin的依赖,如下:
<!--链路追踪 zipkin依赖,其中包含Sleuth的依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
注意:由于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
上述配置完成后启动服务即可,此时访问:http://localhost:9031/order/get/12
调用接口之后,再次访问zipkin的UI界面,
可以看到刚才调用的接口已经被监控到了,点击SHOW
进入详情查看
可以看到左边展示了一条完整的链路,包括服务名称、耗时,右边展示服务调用的相关信息,包括开始、结束时间、请求url,请求方式…..
除了调用链路的相关信息,还可以清楚看到每个服务的依赖如下图
zipkin默认的传输方式是HTTP,但是这里存在一个问题,一旦传输过程中客户端和服务端断掉了,那么这条跟踪日志信息将会丢失。
当然zipkin还支持MQ方式的传输,支持消息中间件有如下几种:
使用MQ方式传输不仅能够保证消息丢失的问题,还能提高传输效率,生产中推荐MQ传输方式。
那么问题来了,如何切换呢?
其实方式很简单,下面陈某以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
命令分析如下:
zipkin.collector.rabbitmq.addresses
:MQ地址zipkin.collector.rabbitmq.username
:用户名zipkin.collector.rabbitmq.password
:密码既然使用MQ传输,肯定是要添加对应的依赖和配置了,添加RabbitMQ依赖如下:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-amqp</artifactId>
</dependency>
配置MQ的地址、用户名、密码,配置如下:
spring:
rabbitmq:
addresses: 127.0.0.1
username: guest
password: guest
spring.cloud.zipkin.sender.type
这个配置就是用来切换传输方式的,取值为rabbit
则表示使用rabbitMQ进行数据传输。
配置如下:
spring:
cloud:
zipkin:
sender:
## 使用rabbitMQ进行数据传输
type: rabbit
注意:使用MQ传输,则spring.cloud.zipkin.sender.base-url
可以去掉。
既然使用MQ传输,那么我们不启动服务端也是能够成功传输的,浏览器访问:http://localhost: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支持以下四种存储方式:
今天陈某就以MySQL为例介绍一下zipkin如何持久化,Elasticsearch放在下一篇,篇幅有点长。
zipkin服务端的MySQL建表SQL在源码中的zipkin-storage/mysql-v1/src/main/resources/mysql.sql
中,这份SQL文件我会放在案例源码中。
创建的数据库:zipkin(名称任意),导入建表SQL,新建的数据库表如下图
服务端配置很简单,运行如下命令:
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服务端的所有配置项都在这里,没事去翻翻看。
那么采用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
持久化是服务端做的事,和客户端无关,因此到这就完事了,陈某就不再测试了,自己动手试试吧。
前面介绍了这么多,不知道大家有没有仔细看,陈某总结一下吧: