分布式链路追踪之Spring Cloud Sleuth夺命连环9问?

本文涉及的产品
数据传输服务 DTS,数据同步 small 3个月
推荐场景:
数据库上云
数据传输服务 DTS,数据迁移 small 3个月
推荐场景:
MySQL数据库上云
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介: 分布式链路追踪之Spring Cloud Sleuth夺命连环9问?

今天这篇文章陈某介绍一下链路追踪相关的知识,以Spring Cloud Sleuthzipkin这两个组件为主,后续文章介绍另外一种。

文章的目录如下:

为什么需要链路追踪?

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

服务之间的调用错综复杂,对于维护的成本成倍增加,势必存在以下几个问题:

  • 服务之间的依赖与被依赖的关系如何能够清晰的看到?
  • 出现异常时如何能够快速定位到异常服务?
  • 出现性能瓶颈时如何能够迅速定位哪个服务影响的?

为了能够在分布式架构中快速定位问题,分布式链路追踪应运而生。将一次分布式请求还原成调用链路,进行日志记录,性能监控并将一次分布式请求的调用情况集中展示。比如各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态等等。

常见的链路追踪技术有哪些?

市面上有很多链路追踪的项目,其中也不乏一些优秀的,如下:

  • cat:由大众点评开源,基于Java开发的实时应用监控平台,包括实时应用监控,业务监控 。集成方案是通过代码埋点的方式来实现监控,比如:拦截器,过滤器等。对代码的侵入性很大,集成成本较高,风险较大。
  • zipkin:由Twitter公司开源,开放源代码分布式的跟踪系统,用于收集服务的定时数据,以解决微服务架构中的延迟问题,包括:数据的收集、存储、查找和展现。该产品结合spring-cloud-sleuth使用较为简单, 集成很方便, 但是功能较简单。
  • pinpoint:韩国人开源的基于字节码注入的调用链分析,以及应用监控分析工具。特点是支持多种插件,UI功能强大,接入端无代码侵入
  • skywalking:SkyWalking是本土开源的基于字节码注入的调用链分析,以及应用监控分析工具。特点是支持多种插件,UI功能较强,接入端无代码侵入。目前已加入Apache孵化器。
  • Sleuth:SpringCloud 提供的分布式系统中链路追踪解决方案。很可惜的是阿里系并没有链路追踪相关的开源项目,我们可以采用Spring Cloud Sleuth+Zipkin来做链路追踪的解决方案。

Spring Cloud Sleuth是什么?

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

Spring Cloud Sleuth只负责产生监控数据,通过日志的方式展示出来,并没有提供可视化的UI界面。

学习Sleuth之前必须了解它的几个概念:

  • Span:基本的工作单元,相当于链表中的一个节点,通过一个唯一ID标记它的开始、具体过程和结束。我们可以通过其中存储的开始和结束的时间戳来统计服务调用的耗时。除此之外还可以获取事件的名称、请求信息等。
  • Trace:一系列的Span串联形成的一个树状结构,当请求到达系统的入口时就会创建一个唯一ID(traceId),唯一标识一条链路。这个traceId始终在服务之间传递,直到请求的返回,那么就可以使用这个traceId将整个请求串联起来,形成一条完整的链路。
  • Annotation:一些核心注解用来标注微服务调用之间的事件,重要的几个注解如下:
  • cs(Client Send):客户端发出请求,开始一个请求的生命周期
  • sr(Server Received):服务端接受请求并处理;sr-cs = 网络延迟 = 服务调用的时间
  • ss(Server Send):服务端处理完毕准备发送到客户端;ss - sr = 服务器上的请求处理时间
  • cr(Client Reveived):客户端接受到服务端的响应,请求结束;cr - sr = 请求的总时间

Spring Cloud 如何整合Sleuth?

整合Spring Cloud Sleuth其实没什么的难的,在这之前需要准备以下三个服务:

  • gateway-sleuth9031:作为网关服务
  • sleuth-product9032:商品微服务
  • sleuth-order9033:订单微服务

三个服务的调用关系如下图:

客户端请求网关发起查询订单的请求,网关路由给订单服务,订单服务获取订单详情并且调用商品服务获取商品详情。

添加依赖

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

<dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

以上只是Spring Cloud Sleuth的依赖,还有NacosopenFeign的依赖这里就不再详细说了,有不清楚的可以结合陈某前面几篇文章和案例源码补漏一下。

调整日志级别

由于sleuth并没有UI界面,因此需要调整一下日志级别才能在控制台看到更加详细的链路信息。

在三个服务的配置文件中添加以下配置:

## 设置openFeign和sleuth的日志级别为debug,方便查看日志信息
logging:
  level:
    org.springframework.cloud.openfeign: debug
    org.springframework.cloud.sleuth: debug

演示接口完善

以下接口只是为了演示造的数据,并没有整合DB。

sleuth-order9033查询订单详情的接口,如下图:

sleuth-product9032的查询商品详情的接口,如下图:

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

测试

启动上述三个服务,浏览器直接访问:http://localhost:9031/order/get/12

观察控制台日志输出,如下图:

日志格式中总共有四个参数,含义分别如下:

  • 第一个:服务名称
  • 第二个:traceId,唯一标识一条链路
  • 第三个:spanId,链路中的基本工作单元id
  • 第四个:表示是否将数据输出到其他服务,true则会把信息输出到其他可视化的服务上观察,这里并未整合zipkin,所以是false

好了,至此整合完成了,不禁心里倒吸一口凉气,直接看日志那不是眼睛要看瞎了..........

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

什么是ZipKin?

Zipkin 是 Twitter 的一个开源项目,它基于Google Dapper实现,它致力于收集服务的定时数据,

以解决微服务架构中的延迟问题,包括数据的收集、存储、查找和展现

ZipKin的基础架构如下图:

Zipkin共分为4个核心的组件,如下:

  • Collector:收集器组件,它主要用于处理从外部系统发送过来的跟踪信息,将这些信息转换为Zipkin内部处理的 Span 格式,以支持后续的存储、分析、展示等功能。
  • Storage:存储组件,它主要对处理收集器接收到的跟踪信息,默认会将这些信息存储在内存中,我们也可以修改此存储策略,通过使用其他存储组件将跟踪信息存储到数据库中
  • RESTful API:API 组件,它主要用来提供外部访问接口。比如给客户端展示跟踪信息,或是外接系统访问以实现监控等。
  • UI:基于API组件实现的上层应用。通过UI组件用户可以方便而有直观地查询和分析跟踪信息

zipkin分为服务端和客户端,服务端主要用来收集跟踪数据并且展示,客户端主要功能是发送给服务端,微服务的应用也就是客户端,这样一旦发生调用,就会触发监听器将sleuth日志数据传输给服务端。

zipkin服务端如何搭建?

首先需要下载服务端的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的依赖,如下:

<!--链路追踪 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的数据传输方式如何切换?

zipkin默认的传输方式是HTTP,但是这里存在一个问题,一旦传输过程中客户端和服务端断掉了,那么这条跟踪日志信息将会丢失。

当然zipkin还支持MQ方式的传输,支持消息中间件有如下几种:

  • ActiveMQ
  • RabbitMQ
  • Kafka

使用MQ方式传输不仅能够保证消息丢失的问题,还能提高传输效率,生产中推荐MQ传输方式

那么问题来了,如何切换呢?

其实方式很简单,下面陈某以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

命令分析如下:

  • zipkin.collector.rabbitmq.addresses:MQ地址
  • zipkin.collector.rabbitmq.username:用户名
  • zipkin.collector.rabbitmq.password:密码

2、客户端添加RabbitMQ

既然使用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

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

spring.cloud.zipkin.sender.type这个配置就是用来切换传输方式的,取值为rabbit则表示使用rabbitMQ进行数据传输。

配置如下:

spring:
  cloud:
  zipkin:
    sender:
     ## 使用rabbitMQ进行数据传输
      type: rabbit

注意:使用MQ传输,则spring.cloud.zipkin.sender.base-url可以去掉。

完整的配置如下图:

4、测试

既然使用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提供了可插拔式的存储。

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

  • 内存:服务重启将会失效,不推荐
  • MySQL:数据量越大性能较低
  • Elasticsearch:主流的解决方案,推荐使用
  • Cassandra:技术太牛批,用的人少,自己选择,不过官方推荐

今天陈某就以MySQL为例介绍一下zipkin如何持久化,Elasticsearch放在下一篇,篇幅有点长。

1、创建数据库

zipkin服务端的MySQL建表SQL在源码中的zipkin-storage/mysql-v1/src/main/resources/mysql.sql中,这份SQL文件我会放在案例源码中。

github地址:https://github.com/openzipkin/zipkin/blob/master/zipkin-storage/mysql-v1/src/main/resources/mysql.sql

创建的数据库: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

上述命令参数分析如下:

  • STORAGE_TYPE:指定存储的方式,默认内存形式
  • MYSQL_HOST:MySQL的ip地址,默认localhost
  • MYSQL_TCP_PORT:MySQL的端口号,默认端口3306
  • MYSQL_DB:MySQL中的数据库名称,默认是zipkin
  • MYSQL_USER:用户名
  • MYSQL_PASS:密码

陈某是如何记得这些参数的?废话,肯定记不住,随时查看下源码不就得了,这些配置都在源码的/zipkin-server/src/main/resources/zipkin-server-shared.yml这个配置文件中,比如上述MySQL的相关配置,如下图:

zipkin服务端的所有配置项都在这里,没事去翻翻看。

github地址:https://github.com/openzipkin/zipkin/blob/master/zipkin-server/src/main/resources/zipkin-server-shared.yml

那么采用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

持久化是服务端做的事,和客户端无关,因此到这就完事了,陈某就不再测试了,自己动手试试吧。

总结

前面介绍了这么多,不知道大家有没有仔细看,陈某总结一下吧:

  • Spring Cloud Sleuth 作为链路追踪的一种组件,只提供了日志采集,日志打印的功能,并没有可视化的UI界面
  • zipkin提供了强大的日志追踪分析、可视化、服务依赖分析等相关功能,结合Spring Cloud Sleuth作为一种主流的解决方案
  • zipkin生产环境建议切换的MQ传输模式,这样做有两个优点
  • 防止数据丢失
  • MQ异步解耦,性能提升很大
  • zipkin默认是内存的形式存储,MySQL虽然也是一种方式,但是随着数据量越大,性能越差,因此生产环境建议采用Elasticsearch,下一篇文章介绍。

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

最后说一句(求关注,别白嫖我)

陈某每一篇原创文章都是精心输出,尤其是《Spring Cloud 进阶》专栏的文章,知识点太多,要想讲的细,必须要花很多时间准备,从知识点到源码demo。

相关实践学习
基于OpenTelemetry构建全链路追踪与监控
本实验将带领您快速上手可观测链路OpenTelemetry版,包括部署并接入多语言应用、体验TraceId自动注入至日志以实现调用链与日志的关联查询、以及切换调用链透传协议以满足全链路打通的需求。
分布式链路追踪Skywalking
Skywalking是一个基于分布式跟踪的应用程序性能监控系统,用于从服务和云原生等基础设施中收集、分析、聚合以及可视化数据,提供了一种简便的方式来清晰地观测分布式系统,具有分布式追踪、性能指标分析、应用和服务依赖分析等功能。 分布式追踪系统发展很快,种类繁多,给我们带来很大的方便。但在数据采集过程中,有时需要侵入用户代码,并且不同系统的 API 并不兼容,这就导致了如果希望切换追踪系统,往往会带来较大改动。OpenTracing为了解决不同的分布式追踪系统 API 不兼容的问题,诞生了 OpenTracing 规范。OpenTracing 是一个轻量级的标准化层,它位于应用程序/类库和追踪或日志分析程序之间。Skywalking基于OpenTracing规范开发,具有性能好,支持多语言探针,无侵入性等优势,可以帮助我们准确快速的定位到线上故障和性能瓶颈。 在本套课程中,我们将全面的讲解Skywalking相关的知识。从APM系统、分布式调用链等基础概念的学习加深对Skywalking的理解,从0开始搭建一套完整的Skywalking环境,学会对各类应用进行监控,学习Skywalking常用插件。Skywalking原理章节中,将会对Skywalking使用的agent探针技术进行深度剖析,除此之外还会对OpenTracing规范作整体上的介绍。通过对本套课程的学习,不止能学会如何使用Skywalking,还将对其底层原理和分布式架构有更深的理解。本课程由黑马程序员提供。
相关文章
|
4月前
|
资源调度 Java 调度
Spring Cloud Alibaba 集成分布式定时任务调度功能
定时任务在企业应用中至关重要,常用于异步数据处理、自动化运维等场景。在单体应用中,利用Java的`java.util.Timer`或Spring的`@Scheduled`即可轻松实现。然而,进入微服务架构后,任务可能因多节点并发执行而重复。Spring Cloud Alibaba为此发布了Scheduling模块,提供轻量级、高可用的分布式定时任务解决方案,支持防重复执行、分片运行等功能,并可通过`spring-cloud-starter-alibaba-schedulerx`快速集成。用户可选择基于阿里云SchedulerX托管服务或采用本地开源方案(如ShedLock)
143 1
|
18天前
|
存储 NoSQL Java
使用lock4j-redis-template-spring-boot-starter实现redis分布式锁
通过使用 `lock4j-redis-template-spring-boot-starter`,我们可以轻松实现 Redis 分布式锁,从而解决分布式系统中多个实例并发访问共享资源的问题。合理配置和使用分布式锁,可以有效提高系统的稳定性和数据的一致性。希望本文对你在实际项目中使用 Redis 分布式锁有所帮助。
47 5
|
21天前
|
消息中间件 监控 Java
如何将Spring Boot + RabbitMQ应用程序部署到Pivotal Cloud Foundry (PCF)
如何将Spring Boot + RabbitMQ应用程序部署到Pivotal Cloud Foundry (PCF)
31 6
|
19天前
|
缓存 NoSQL Java
Spring Boot中的分布式缓存方案
Spring Boot提供了简便的方式来集成和使用分布式缓存。通过Redis和Memcached等缓存方案,可以显著提升应用的性能和扩展性。合理配置和优化缓存策略,可以有效避免常见的缓存问题,保证系统的稳定性和高效运行。
37 3
|
21天前
|
Java 关系型数据库 MySQL
如何将Spring Boot + MySQL应用程序部署到Pivotal Cloud Foundry (PCF)
如何将Spring Boot + MySQL应用程序部署到Pivotal Cloud Foundry (PCF)
39 5
|
21天前
|
缓存 监控 Java
如何将Spring Boot应用程序部署到Pivotal Cloud Foundry (PCF)
如何将Spring Boot应用程序部署到Pivotal Cloud Foundry (PCF)
31 5
|
26天前
|
存储 Java 关系型数据库
在Spring Boot中整合Seata框架实现分布式事务
可以在 Spring Boot 中成功整合 Seata 框架,实现分布式事务的管理和处理。在实际应用中,还需要根据具体的业务需求和技术架构进行进一步的优化和调整。同时,要注意处理各种可能出现的问题,以保障分布式事务的顺利执行。
46 6
|
2月前
|
监控 Java 对象存储
监控与追踪:如何利用Spring Cloud Sleuth和Netflix OSS工具进行微服务调试
监控与追踪:如何利用Spring Cloud Sleuth和Netflix OSS工具进行微服务调试
50 1
|
3月前
|
消息中间件 Java 对象存储
数据一致性挑战:Spring Cloud与Netflix OSS下的分布式事务管理
数据一致性挑战:Spring Cloud与Netflix OSS下的分布式事务管理
60 2
|
4月前
|
Java 微服务 Spring
SpringBoot+Vue+Spring Cloud Alibaba 实现大型电商系统【分布式微服务实现】
文章介绍了如何利用Spring Cloud Alibaba快速构建大型电商系统的分布式微服务,包括服务限流降级等主要功能的实现,并通过注解和配置简化了Spring Cloud应用的接入和搭建过程。
SpringBoot+Vue+Spring Cloud Alibaba 实现大型电商系统【分布式微服务实现】
下一篇
DataWorks