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

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群版 2核4GB 100GB
推荐场景:
搭建个人博客
可观测链路 OpenTelemetry 版,每月50GB免费额度
简介: 【分布式链路追踪技术】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,还将对其底层原理和分布式架构有更深的理解。本课程由黑马程序员提供。
目录
相关文章
|
6天前
|
并行计算 安全 数据处理
探索操作系统的未来:量子计算与分布式技术的融合
随着量子计算的逐步成熟和分布式技术的快速发展,传统的操作系统面临着前所未有的挑战与机遇。本文将探讨如何通过结合量子计算原理和分布式系统设计,来构建未来操作系统的新范式。我们将分析当前操作系统的限制,阐述量子计算和分布式技术的优势,以及它们如何共同推动操作系统设计的革新。
|
23天前
|
弹性计算 运维 负载均衡
构建高可用性的分布式系统:技术与策略
【7月更文挑战第1天】构建高可用分布式系统涉及负载均衡、容错处理和数据一致性等关键技术,遵循冗余、模块化及异步设计原则,并通过监控告警、自动化运维和弹性伸缩策略确保稳定性。
|
3天前
|
存储 数据管理 数据库
现代数据库技术中的分布式一致性问题与解决方案探讨
分布式系统在现代数据库技术中扮演着重要角色,但分布式环境下的数据一致性问题始终是挑战之一。本文深入探讨了分布式一致性的核心概念、各种一致性模型的特点及其在实际应用中的优缺点,旨在为技术从业者提供全面的视角和实用的解决方案。
|
27天前
|
NoSQL 前端开发 Java
技术笔记:springboot分布式锁组件spring
技术笔记:springboot分布式锁组件spring
18 1
|
27天前
|
NoSQL 算法 Java
技术好文:Redis实现分布式锁的7种方案
技术好文:Redis实现分布式锁的7种方案
|
12天前
|
NoSQL 安全 Java
技术好文:Redis分布式锁的正确实现方式
技术好文:Redis分布式锁的正确实现方式
12 0
|
20天前
|
缓存 Devops 微服务
微服务01好处,随着代码越多耦合度越多,升级维护困难,微服务技术栈,异步通信技术,缓存技术,DevOps技术,搜索技术,单体架构,分布式架构将业务功能进行拆分,部署时费劲,集连失败如何解决
微服务01好处,随着代码越多耦合度越多,升级维护困难,微服务技术栈,异步通信技术,缓存技术,DevOps技术,搜索技术,单体架构,分布式架构将业务功能进行拆分,部署时费劲,集连失败如何解决
|
23天前
|
消息中间件 存储 缓存
使用Java构建高可用的分布式系统的关键技术
使用Java构建高可用的分布式系统的关键技术
|
27天前
|
存储 Java C++
技术心得记录:分布式文件系统KFS基础知识介绍
技术心得记录:分布式文件系统KFS基础知识介绍
|
27天前
|
存储 关系型数据库 Java
技术经验解读:三种分布式事务LCN、Seata、MQ
技术经验解读:三种分布式事务LCN、Seata、MQ
30 0