springcloud实战：服务链路追踪Sleuth

本文主要是介绍springcloud实战：服务链路追踪Sleuth，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

服务链路追踪:Spring Cloud Sleuth

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

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

Spring Cloud Sleuth简介

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

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

span(跨度):基本工作单元。在一个新建的 span中发送一个RPC，相当于发送一个回应给RPC。span被一个唯一的64位ID标识，它还有其他数据信息，比如摘要、时间戳事件、关键值注释( tags )以及进度ID(通常是地址)。span 在不断地启动和停止，同时记录了时间信息，当你创建了一个span，你必须在未来的某个时刻停止它。
trace(追踪):一组共享root span的 span组成的树状结构称为trace。trace也用一个64位的ID唯一标识，trace中的所有span都共享该trace的 ID。
annotation(标注):用来实时记录一个事件的存在，一些核心annotations 用来定义一个请求的开始和结束。
cs，即client sent，客户端发起一个请求,描述span的开始。
sr，即 server received，服务端获得请求并准备开始处理它，sr时间戳减去cs时间戳可以得到网络延迟。
ss，即server sent，表示请求处理完成(即请求返回客户端)，ss时间戳减去sr时间戳可以得到服务端需要的处理请求时间。
cr，即 client received，表明span 的结束，客户端成功接收到服务端的回复，cr时间戳减去cs时间戳可以得到客户端从服务端获取回复所需的时间。

图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