系统相关
首页 > 系统相关> > springcloud实战:服务链路追踪Sleuth,深入linux内核架构mobi

springcloud实战:服务链路追踪Sleuth,深入linux内核架构mobi

作者:互联网

==========================

我们知道,微服务之间通过网络进行通信,但在我们提供服务的同时,不能保证网络一定是畅通的。相反地,网络是很脆弱的,网络资源也有限,因此我们有必要追踪每个网络请求,了解它们经过了哪些微服务,延迟多少,每个请求所耗费的时间等。只有这样能更好地分析系统瓶颈,解决系统问题。

在Spring Cloud 中,我们可以使用Spring Cloud Sleuth组件来实现微服务追踪。

Spring Cloud Sleuth简介

=====================

我们知道,Spring Cloud不重复造轮子,Spring Cloud Sleuth也不例外,它集成了非常强大的跟踪系统——Zipkin。Zipkin是Twitter开源的分布式跟踪系统,基于Dapper的论文设计而来。它的主要功能是收集系统的时序数据”,从而追踪微服务架构的系统延时。

在学习Spring Cloud Sleuth之前,我们先来认识一些基本术语。

图12-1演示了请求依次经过SERVICE1→SERVICE2一SERVICE3→SERVICE4时,span、trace、annotation的变化。

springcloud实战:服务链路追踪Sleuth

利用链路追踪监听网络请求

============

本节我们将在项目中集成Spring Cloud Sleuth来监听每个请求,从而更好地优化系统架构。我们知道,Spring Cloud Sleuth底层其实是Zipkin,而Zipkin分为服务端和客户端。如果服务端用户开启链路追踪服务,那么客户端在进行网络请求时就需要和Zipkin 的服务端进行通信。

下面我们就来分别实现服务端和客户端。

服务端的实现

以前,我们需要自己实现Zipkin服务端,但从Spring Boot 2.0以后,官方推出了Zipkin服务端,我们只需要把下载好的服务端jar包放到服务器上启动即可。具体操作如下。

(1)从网络上下载Zipkin服务端的可执行jar包,下载地址: https:/repo1.maven.org/maven2/io/zipkin/java/zipkin-server/2.9.4/zipkin-server-2.9.4-exec.jar。

(2)将zipkin-server-2.9.4-exec.jar修改为zipkin.jar。

(3)执行下面的命令进入zipkin.jar所在目录:

java -jar zipkin.jar

启动成功后,会出现如图12-2所示的界面。

springcloud实战:服务链路追踪Sleuth

Zipkin服务端的默认启动端口为9411,浏览器访问localhost:9411即可进入Zipkin服务端管理界面,如图12-3所示。

![sprin

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

gcloud实战:服务链路追踪Sleuth](https://www.icode9.com/i/ll/?i=img_convert/508680b7d8726735cc71ad61d693a342.png)

Spring Boot官方推荐使用此方式。当然,读者也可以自己实现Zipkin服务端。接下来,将介绍如何实现自己的Zipkin服务端。

(1)在blog父工程中创建一个 Module,命名为zipkin,在pom.xml中添加以下依赖:

io.zipkin.java

zipkin-server</ artifactId>2.8.4

io.zipkin.java

zipkin-autoconfigure-ui2.8.4

在上述配置中,zipkin-server是Zipkin的服务端依赖,zipkin-autoconfigure-ui是Zipkin的管理界面依赖。Zipkin提供了Web管理界面,方便我们追踪查看,因此有必要依赖它。

(2)创建工程启动类并加入Zipkin注解:

@SpringBootApplication@EnablezipkinServer

public class ZipkinApplication {

public static void main(String[] args){

SpringApplication.run(ZipkinApplication.class,args);

}

}

其中,@EnableZipkinServer注解表示开启Zipkin服务端。

(3)创建配置文件application.yml :

server:

port: 9411management:

metrics:

web:

server:

auto-time-requests: false

auto-time-requests默认为true,该配置的作用是标识Spring MVC或WebFlux处理的请求是否自动计时,如果要使用计时器可以在每个接口方法处添加@Timed注解。需要注意的是,在Spring Boot 2.0以后,需要将auto-time-requests设置为false,否则会抛出java.lang.IllegalAngumentException异常。

(4)运行ZipkinApplication.jar,启动Zipkin服务端,通过浏览器访问localhost:9411,依然可以看到图12-3所示的界面。

客户端集成Spring Cloud Sleuth

单纯启动Zipkin服务端还达不到追踪的目的,我们还必须让微服务客户端集成Zipkin才能跟踪微服务。下面是集成Spring Cloud Sleuth的步骤。

(1)在common工程的pom.xml文件中添加以下依赖:

org.springframework.cloud

spring-cloud-sleuth-zipkin

(2)在Git仓库的配置文件eurekaclient.yml中添加以下内容:

spring:

zipkin:

base-url: http://localhost:9411sender:

type: web

sleuth:

sampler:

probability : 1

其中,spring.zipkin.base-url用来指定Zipkin服务端的地址; spring.sleutch.sampler.probability用来指定采样请求的百分比(默认为0.1,即 10%); spring.zipkin.sender.type为追踪日志发送类型,可选值有web、kafka、rabbit,默认为空,因此必须进行设置,否则·Zipkin 不知道以何种类型发送日志,就无法正确追踪服务链路。

(3)依次启动注册中心、配置中心和 test 工程,浏览器访问localhost:9999/test和 localhost:9411,进入Zipkin界面后,可以看到trace列表,选择Service Name为 test后点击Find a trace按钮,如图12-4所示。

springcloud实战:服务链路追踪Sleuth

注意这里test工程需要引入eurekaclient.yml配置文件。在上述界面中,Find Traces按钮以上为搜索条件,Service Name为服务名,当前只访问了test,因此下拉框中只能看到test和 all,all为查询所有服务;Span Name为基本工作单元名,顾名思义为具体请求名,一个请求就是一个span;Lookback为记录时间; Annotations Query为自定义的查询条件,可以对标签进行查询,多个用and 隔开; Duration为服务调用时间,查询大于等于该时间的服务,单位是微秒(需要注意的是,下方的服务请求日志列表中以毫秒为单位,所以在筛选条件时需要进行一次转换,否则无法查询出正确的数据);Limit为显示数量,默认为10;Sort为排序规则。

Find Traces按钮下方,Showing表示当前请求数量,Services为当前选择的服务名,点击右边的JSON可以看到当前请求的JSON结构;下方列表展示了当前的请求情况,包括请求总耗时(单位为毫秒)、调用的时间、span的数量、请求耗时占比等。

在实际项目中,读者可以根据Zipkin统计的这些信息发现速度较慢的请求或查询,从而有针对性地对指定请求进行优化。

通过消息中间件实现链路追踪

=============

上一节,我们集成了服务链路追踪组件Zipkin,客户端通过指定Zipkin提供的HTTP地址即可完成日志收集。我们知道,客户端可以通过spring.zipkin.sender.type 指定发送类型,除了指定为web 类型还可以通过消息中间件来收集日志。

本节将利用消息中间件RabbitMQ来完成服务链路追踪日志的收集。

(1)命令行启动官网提供的zipkin.jar,注意,启动时需要指定RabbitMQ 的 host地址,如:

java -jar zipkin.jar --RABBIT_ADDRESSES=127.0.0.1

其中,–RABBIT_ADDRESSES即为RabbitMQ的host地址。

启动完成后,我们访问RabbitMQ的Web管理界面,可以看到,Zipkin Server已经为我们创建了一个名叫zipkin的队列,如图12-5所示。

springcloud实战:服务链路追踪Sleuth

(2)在common工程下增加以下依赖:

org.springframework.cloud

spring-cloud-stream-binder-rabbit

</ dependency>

该依赖实现了消息队列的收发机制,添加该依赖后,客户端就可以通过 RabbitMQ发送消息,ZipkinServer就可以通过RabbitMQ收集日志。

(3)将eurekaclient.xml的spring.zipkin.base-url注释掉并重启test工程,分别访问test工程接口和Zipkin的Web界面,正常情况下读者可以看到与图12-4类似的效果。

存储追踪数据

======

在前面的操作中,不管是基于Web还是基于消息中间件,收集的日志都默认存放在内存中,即Zipkin Server重启后,追踪的链路数据将被清除,这不符合我们的期望。比较合理的做法是将数据持久化,比如持久化到MySQL、MongoDB、ElasticSearch、Cassandra等数据库中。

下面以MySQL为例,演示如何将追踪数据存储到数据库中。

(1)创建数据库zipkin_db(名字可以随意取)并生成数据表(MySQL 的详细安装过程请查看第14章,Zipkin Server官方推荐使用MariaDB ):

标签:Sleuth,mobi,span,请求,Zipkin,springcloud,zipkin,Spring,服务端
来源: https://blog.csdn.net/m0_65320833/article/details/122084292