Spring Cloud项目（九）——使用sleuth+zipkin进行服务链路追踪

最新推荐文章于 2023-06-19 09:44:24 发布

--流星。

最新推荐文章于 2023-06-19 09:44:24 发布

阅读量335

点赞数

分类专栏： Spring实战微服务文章标签： spring cloud 微服务 sleuth zipkin

本文链接：https://blog.csdn.net/weixin_45974176/article/details/127005306

版权

Spring实战同时被 2 个专栏收录

52 篇文章 11 订阅

订阅专栏

微服务

18 篇文章 0 订阅

订阅专栏

前期准备

1、一个简单的微服务项目，以之前的springcloud-provider、springcloud-consumer、springcloud-gateway为例
2、一台用docker安装mysql8的服务器

代码部分

1、pom文件

        <!--链路追踪 zipkin依赖，其中包含Sleuth的依赖-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zipkin</artifactId>
        </dependency>

2、yml文件

spring:
  sleuth:
    sampler:
      # 日志数据采样百分比，默认0.1(10%)，这里为了测试设置成了100%，生产环境只需要0.1即可
      probability: 1.0
  zipkin:
    #zipkin server的请求地址
    base-url: http://ip地址:9411
    #让nacos把它当成一个URL，而不要当做服务名
    discovery-client-enabled: false
## 设置openFeign和sleuth的日志级别为debug，方便查看日志信息
logging:
  level:
    org.springframework.cloud.openfeign: debug
    org.springframework.cloud.sleuth: debug

注：在你想要追踪的应用上添加上面的代码（我在springcloud-provider、springcloud-consumer、springcloud-gateway上都添加了）

测试结果

启动springcloud-provider、springcloud-consumer、springcloud-gateway应用
发送请求信息
在这里插入图片描述

为什么需要链路追踪？

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

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

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

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

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 = 请求的总时间

什么是ZipKin？

Zipkin 是 Twitter 的一个开源项目，它基于Google Dapper实现，它致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。

ZipKin的基础架构如下图：
在这里插入图片描述

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

Collector：收集器组件，它主要用于处理从外部系统发送过来的跟踪信息，将这些信息转换为Zipkin内部处理的 Span格式，以支持后续的存储、分析、展示等功能。

Storage：存储组件，它主要对处理收集器接收到的跟踪信息，默认会将这些信息存储在内存中，我们也可以修改此存储策略，通过使用其他存储组件将跟踪信息存储到数据库中

RESTful API：API 组件，它主要用来提供外部访问接口。比如给客户端展示跟踪信息，或是外接系统访问以实现监控等。

UI：基于API组件实现的上层应用。通过UI组件用户可以方便而有直观地查询和分析跟踪信息

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

docker安装zipkin并持久化到mysql中

1、在mysql创建名为zipkin的数据库

zipkin表的创建语句

创建完成

2、docker安装zipkin

docker  run --name zipkin-server -d --restart=always -p 9411:9411 -e MYSQL_USER=root -e MYSQL_PASS=admin -e MYSQL_HOST=127.0.0.1 -e STORAGE_TYPE=mysql -e MYSQL_DB=zipkin -e MYSQL_TCP_PORT=3306 openzipkin/zipkin:2.21.7

附：参考链接

1、Docker搭建Zipkin，实现数据持久化到Mysql、ES
2、分布式链路追踪之Spring Cloud Sleuth+Zipkin最全教程！

附：Spring Cloud学习系列

Spring Cloud项目（一）——集成Nacos作为注册中心
 Spring Cloud项目（二）——集成Nacos作为配置中心
 Spring Cloud项目（三）——实现Nacos数据信息持久化到MySQL
Spring Cloud项目（四）——使用Ribbon作为负载均衡
 Spring Cloud项目（五）——使用openFeign作为服务调用
 Spring Cloud项目（六）——使用sentinel作为流量管理
 Spring Cloud项目（七）——使用sentinel作为限流和熔断
 Spring Cloud项目（八）——使用gateway作为服务网关