【分布式链路追踪技术】sleuth+zipkin

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介: 【分布式链路追踪技术】sleuth+zipkin

1.概述

当采用分布式架构后,一次请求会在多个服务之间流转,组成单次调用链的服务往往都分散在不同的服务器上。这就会带来一个问题:

故障难以溯源。

发起请求,然后请求报错,到底是调用链中哪一环出了问题?很难以定位。这时候就需要用到链路追踪技术了。所谓的链路追踪技术,也就是想办法让分布式系统中的单次请求的链路调用成为可被追踪的,便于在出现故障的时候进行快速的定位溯源。

目前有两套实现思路:

  • 基于日志来实现,常用到的有Sleuth、zipkin
  • 基于agent来实现,常用到的有skywaiking

本文讲解的是其中基于日志实现的sleuth以及其配套的可视化套件zipkin。

关于分布式链路追踪作者上文讲过详细的概论:

https://bugman.blog.csdn.net/article/details/135175596?spm=1001.2014.3001.5502

2.搭建演示工程

本次用于演示的工程很简单,用spring cloud来搭建三个服务,一个app服务用来提供服务,一个鉴权中心用来登录以及鉴权,一个bis服务用来聚合:

在bis中调用鉴权中心来登录获取token,然后校验token,校验通过后调用app提供的服务:

3.sleuth

依赖:

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

去访问bis,会看到:

bis的日志:

AuthenticationCenter的日志:


APP的日志:

我想到这里很多读者会有个疑问。

问:

sleuth这么保证一个链路上的traceID是相同的?

答:

当一个请求进入 Spring Cloud 的微服务系统时,Sleuth 会生成一个唯一的 Trace ID。如果请求是从另一个使用 Sleuth 的服务传入的,Sleuth 会提取并使用该服务传入的 Trace ID。Sleuth 集成了这些通信协议,如HTTP协议,并在服务间调用时自动将 Trace ID 添加到 HTTP 请求的头部、消息的元数据等中。

4.zipkin

光有了日志,进行问题排查还是要一条条的翻,还是很繁琐。所以配套出现了可视化套件,由推特开发的——zipkin。其能对标准opentracing格式的日志进行收集和展示。zipkin采用的标准的CS架构,client向server发数据。


服务端:

服务端是一个jar包,直接跑起来就可以,下载地址:

Central Repository: io/zipkin/zipkin-server

客户端:

依赖:

<dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-zipkin</artifactId>
   <version>2.2.1.RELEASE</version>
</dependency>
 

配置:

#zipkin server地址
spring.zipkin.base-url=http://localhost:9411/
#client向server发送数据的方式,web,http报文
spring.zipkin.sender.type=web

效果:

zipkin的启动日志里已经清晰的告诉了Web界面的访问地址是多少:

访问127.0.0.1:9411/可以看到:

点进链路可以看到单次请求的详细内容:

5.插拔式存储

zipkin从各个client中收集到的server上的数据存到哪儿去?默认是将数据存储在内存中,除此之外zipkin还支持多种数据的存储方式,如mysql、ES等,根据场景需要可自行切换。

5.1.存储到MySQL中

要存储到MySQL中首先当然是要先建表,zipkin在项目文件中自带了mysql的建表脚本:

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

server的源码工程的配置文件中可以看到,存储默认是内存,参数有默认值,但是支持传参来设置:

所以在用java -jar启动的时候可以通过跟参数的方式来切换存储类型:

java -jar zipkin-server-2.20.1-exec.jar --STORAGE_TYPE=mysql --MYSQL_HOST=localhost --MYSOL_TCP_PORT=3306 --MYSQL_USER=root --MYSQL_PASS=admin --MYSQL_DB=zipkin


这样数据就会存进MySQL中来进行持久化了。

5.2.用MQ来流量削峰

zipkin支持多种数据的存储方式,如mysql、ES等,默认是将数据存储在内存中。

server端:

从配置文件中可以看到,zipkin server支持Kafka、rabbitMQ等多种MQ,具体配置是用启动传参的方式来配置的:

想用哪种MQ,直接去配置即可,这里以rabbitMQ为例:


java -jar zipkin-server-2.20.1-exec.jar --STORAGE_TYPE=mysql --MYSQL_HOST=localhost --MYSOL-TCP-PORT=3306 --MYSOL_USER=root --MYSQL_PASS=admin --MYSQL_DB=zipkin --RABBIT_ADDRESSES=10.1.2.10:5672 --RABBIT_USER=quest --RABBIT_PASSWORD=guest --RABBIT_VIRTUAL_HOST=/ --RABBIT_QUEUE=zipkin


client端:


client端增加以下关于mq的配置:


#zipkin server地址

spring.zipkin.base-url=http://localhost:9411/

#client向server发送数据的方式,rabbitmq

spring.zipkin.sender.type=rabbit

#队列名称

spring.zipkin.rabbitmq.queue=zipkin

#服务器IP、端口号、账户名、密码

spring.rabbitmq.host=10.1.2.10

spring.rabbitmq.port=5672

spring.rabbitmq.username=guest

spring.rabbitmq.password=guest

#虚拟主机地址

spring.rabbitmq.virtual-host=/

#是否开启发布重试

spring.rabbitmq.listener.direct.retry.enabled=true

#最大重试次数

spring.rabbitmq.listener.direct.retry.max-attempts=5

#重试间隔时间

spring.rabbitmq.listener.direct.retry.initial-interval=5000

#是否开启消费者重试

spring.rabbitmq.listener.simple.retry.enabled=true

#最大重试次数

spring.rabbitmq.listener.simple.retry.max-attempts=5

#最大间隔时间

spring.rabbitmq.listener.simple.retry.initial-interval=5000

相关实践学习
基于OpenTelemetry构建全链路追踪与监控
本实验将带领您快速上手可观测链路OpenTelemetry版,包括部署并接入多语言应用、体验TraceId自动注入至日志以实现调用链与日志的关联查询、以及切换调用链透传协议以满足全链路打通的需求。
分布式链路追踪Skywalking
Skywalking是一个基于分布式跟踪的应用程序性能监控系统,用于从服务和云原生等基础设施中收集、分析、聚合以及可视化数据,提供了一种简便的方式来清晰地观测分布式系统,具有分布式追踪、性能指标分析、应用和服务依赖分析等功能。 分布式追踪系统发展很快,种类繁多,给我们带来很大的方便。但在数据采集过程中,有时需要侵入用户代码,并且不同系统的 API 并不兼容,这就导致了如果希望切换追踪系统,往往会带来较大改动。OpenTracing为了解决不同的分布式追踪系统 API 不兼容的问题,诞生了 OpenTracing 规范。OpenTracing 是一个轻量级的标准化层,它位于应用程序/类库和追踪或日志分析程序之间。Skywalking基于OpenTracing规范开发,具有性能好,支持多语言探针,无侵入性等优势,可以帮助我们准确快速的定位到线上故障和性能瓶颈。 在本套课程中,我们将全面的讲解Skywalking相关的知识。从APM系统、分布式调用链等基础概念的学习加深对Skywalking的理解,从0开始搭建一套完整的Skywalking环境,学会对各类应用进行监控,学习Skywalking常用插件。Skywalking原理章节中,将会对Skywalking使用的agent探针技术进行深度剖析,除此之外还会对OpenTracing规范作整体上的介绍。通过对本套课程的学习,不止能学会如何使用Skywalking,还将对其底层原理和分布式架构有更深的理解。本课程由黑马程序员提供。
目录
相关文章
|
3月前
|
存储 消息中间件 Java
快速了解分布式跟踪系统 Zipkin
【8月更文挑战第8天】快速了解分布式跟踪系统 Zipkin
55 3
快速了解分布式跟踪系统 Zipkin
|
19天前
|
监控 算法 网络协议
|
18天前
|
存储 NoSQL 关系型数据库
微服务Zipkin链路追踪原理,图解版,一文吃透!
本文重点讲解Zipkin链路追踪的原理与使用,帮助解决微服务架构下的服务响应延迟等问题,提升系统性能与稳定性。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
微服务Zipkin链路追踪原理,图解版,一文吃透!
|
1月前
|
人工智能 文字识别 Java
SpringCloud+Python 混合微服务,如何打造AI分布式业务应用的技术底层?
尼恩,一位拥有20年架构经验的老架构师,通过其深厚的架构功力,成功指导了一位9年经验的网易工程师转型为大模型架构师,薪资逆涨50%,年薪近80W。尼恩的指导不仅帮助这位工程师在一年内成为大模型架构师,还让他管理起了10人团队,产品成功应用于多家大中型企业。尼恩因此决定编写《LLM大模型学习圣经》系列,帮助更多人掌握大模型架构,实现职业跃迁。该系列包括《从0到1吃透Transformer技术底座》、《从0到1精通RAG架构》等,旨在系统化、体系化地讲解大模型技术,助力读者实现“offer直提”。此外,尼恩还分享了多个技术圣经,如《NIO圣经》、《Docker圣经》等,帮助读者深入理解核心技术。
SpringCloud+Python 混合微服务,如何打造AI分布式业务应用的技术底层?
|
2月前
|
人工智能 Kubernetes Cloud Native
深度对话 解锁阿里云分布式云原生技术落地新姿势
深度对话 解锁阿里云分布式云原生技术落地新姿势
深度对话 解锁阿里云分布式云原生技术落地新姿势
因为一个问题、我新学了一门技术 ElasticSearch 分布式搜索
这篇文章讲述了作者因为一个检索问题而学习了ElasticSearch技术,并分享了排查和解决ElasticSearch检索结果与页面展示不符的过程。
因为一个问题、我新学了一门技术 ElasticSearch 分布式搜索
|
3月前
|
数据可视化 Java Nacos
Sleuth+Zipkin 实现 SpringCloud 链路追踪
【8月更文挑战第9天】Sleuth+Zipkin 实现 SpringCloud 链路追踪
94 1
Sleuth+Zipkin 实现 SpringCloud 链路追踪
|
3月前
|
存储 缓存 负载均衡
【PolarDB-X 技术揭秘】Lizard B+tree:揭秘分布式数据库索引优化的终极奥秘!
【8月更文挑战第25天】PolarDB-X是阿里云的一款分布式数据库产品,其核心组件Lizard B+tree针对分布式环境优化,解决了传统B+tree面临的数据分片与跨节点查询等问题。Lizard B+tree通过一致性哈希实现数据分片,确保分布式一致性;智能分区实现了负载均衡;高效的搜索算法与缓存机制降低了查询延迟;副本机制确保了系统的高可用性。此外,PolarDB-X通过自适应分支因子、缓存优化、异步写入、数据压缩和智能分片等策略进一步提升了Lizard B+tree的性能,使其能够在分布式环境下提供高性能的索引服务。这些优化不仅提高了查询速度,还确保了系统的稳定性和可靠性。
90 5
|
3月前
|
C# UED 定位技术
WPF控件大全:初学者必读,掌握控件使用技巧,让你的应用程序更上一层楼!
【8月更文挑战第31天】在WPF应用程序开发中,控件是实现用户界面交互的关键元素。WPF提供了丰富的控件库,包括基础控件(如`Button`、`TextBox`)、布局控件(如`StackPanel`、`Grid`)、数据绑定控件(如`ListBox`、`DataGrid`)等。本文将介绍这些控件的基本分类及使用技巧,并通过示例代码展示如何在项目中应用。合理选择控件并利用布局控件和数据绑定功能,可以提升用户体验和程序性能。
66 0
|
3月前
|
存储 负载均衡 中间件
构建可扩展的分布式数据库:技术策略与实践
【8月更文挑战第3天】构建可扩展的分布式数据库是一个复杂而具有挑战性的任务。通过采用数据分片、复制与一致性模型、分布式事务管理和负载均衡与自动扩展等关键技术策略,并合理设计节点、架构模式和网络拓扑等关键组件,可以构建出高可用性、高性能和可扩展的分布式数据库系统。然而,在实际应用中还需要注意解决数据一致性、故障恢复与容错性以及分布式事务的复杂性等挑战。随着技术的不断发展和创新,相信分布式数据库系统将在未来发挥更加重要的作用。