当前位置：首页 > news >正文

SpringCloud复习之Sleuth+Zipkin链路追踪实战

news 来源：原创 2024/11/13 13:20:50

文章目录

- 写作背景
- 为什么要有链路监控
- SpringCloud Sleuth+Zipkin能做什么
- 上手实战
- - 启动一个Zipkin Server
  - 微服务集成Sleuth+Zipkin

写作背景

前面复习了SpringCloud Netflix的几个核心组件，包括Eureka、Ribbon、Feign、Hystrix、Zuul，并进行了Demo级别的实战，主要是通过简单的Demo跑起来，然后通过源码来验证组件的核心功能。今天要复习的是链路监控部分，SpringCloud Sleuth + Zipkin，参考官网SpringCloud Sleuth，本文的书写思路和之前不太一样，这次就是主要在之前搭的微服务基础上集成Sleuth+Zipkin来实战演示，没有源码验证部分。

为什么要有链路监控

在微服务架构下，一次请求往往会涉及多个服务，在系统发生故障的时候，想要快速定位和解决问题，就需要追踪服务请求序列。因此分布式调用链路监控组件在这样的需求下就产生了。

SpringCloud Sleuth+Zipkin能做什么

Spring Cloud Sleuth 为服务之间的调用提供链路追踪，通过 Sleuth 可以很清楚地了解到，一个服务请求经过了哪些服务，每个服务处理花费了多少时间，从而可以很方便地
1、理清各微服务间的调用关系
2、还可很方便地看到每个采样请求的耗时，从而分析出些服务调用比较耗时
3、Sleuth还可以可视化错误，然后集成到Zipkin的界面看到
4、对于调用比较频繁的服务，可以有针对性地进行优化措施

Zipkin是Twitter公司开源的分布式跟踪系统，用于收集服务的定时数据。Zipkin 主要涉及几个组件： Collector （收集 agent 数据）、 Storage （存储）和 Web UI （图形界面）
下面实战我用之前搭的SpringCloud微服务来演示
在这里插入图片描述

上手实战

启动一个Zipkin Server

下载和启动Zipkin可以参考zipkin的github官网https://github.com/openzipkin/zipkin 的quick start模块
在这里插入图片描述
我本地通过Docker Desktop启动一个Zipkin Server

然后按照官网说明打开如下地址

http://your_host:9411/zipkin/

在这里插入图片描述
可以看到Zipkin的UI界面。

微服务集成Sleuth+Zipkin

1、pom.xml文件引入依赖坐标


<!-- 链路追踪sleuth+zipkin 相关 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-sleuth</artifactId>
        </dependency>
        
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zipkin</artifactId>
        </dependency>

2、配置文件application里配置Sleuth采集率和Zipkin的地址

spring:
  sleuth:
    sampler:
      #请求采集的速率，默认时候0.1改成1，不然感觉不到它在工作
      probability: ${zipkin.rate:1}
  zipkin:
    base-url: http://localhost:9411/

3、重启微服务，然后访问接口
在这里插入图片描述我前面复习各个组件的时候搭的服务里，Zuul网关是fc-gateway-zuul，然后fc-service-portal里定义了接口通过OpenFeign调用fc-service-screen服务。访问如下接口

http://localhost:8000/portal/getUser/2

然后去Zipkin的UI界面点击搜索框右边的RUN QUERY
在这里插入图片描述

会看到已经采集到数据了。而且服务的调用链路通过序号1,2,3看的很清楚。点击这个SHOW，可以看到具体的内容
在这里插入图片描述
还可以看到服务之间的依赖关系

我这个只是Demo演示，实际公司里如果要用的话，这种方案里有很多不足，比如
1、Zipkin客户端向Zipkin 服务端发送数据使用的是HTTP的方式，那么就会有个问题，如果Zipkin服务端重启，肯定有发送数据的丢失。针对这个问题，可以修改Zipkin客户端和服务端通信的方式为异步，比如用MQ。
2、目前数据存储是在内存里的，没有持久化，实际公司里使用数据量少的情况可以用Mysql来存储，数据量大的建议使用Elasticsearch来存储。
可以参考官网来实现。