前言大家好，我是Milo。今天就带大家来了解一下SpringCloudSleuth。本文主要介绍以下内容。你可能听说过Sleuth一句话，新技术的出现就是为了解决一个痛点问题。在介绍Sleuth之前，我们需要了解在Sleuth之前我们的微服务遇到了哪些问题？1、微服务的现状？前段时间有个大佬说他们公司有几百个微服务。微服务。如果这句话是真的，那么他们公司的微服务调用可能如下图所示：这张来自网络的图很好地说明了微服务调用之间的复杂性。每个前端请求往往需要涉及多个服务。这些服务可能由不同的团队开发，可能使用不同的编程语言来实现，并且可能部署在跨越多个不同数据中心的数千台服务器上。因此，需要一些能够帮助理解系统行为和分析性能问题的工具，以便在出现故障时能够快速定位和解决问题。因此，链接跟踪的思想就被提出来了，而我们今天要讨论的Sleuth就是从这个思想演化而来的分布式跟踪方案。2、微服务追踪解决什么问题？微服务追踪（sleuth）其实是一个工具，可以追踪一个用户请求的过程（包括数据采集、数据传输、数据存储、数据分析、数据可视化），捕获这些追踪数据，可以构建整个调用链的视图微服务，这是调试和监控微服务的关键工具。SpringCloudSleuth有4个特点Sleuth基本术语SpringCloudSleuth使用Google开源项目Dapper的专业术语。Span：工作的基本单位。发送远程调度任务会生成一个Span。Span由64位ID唯一标识。Trace由另一个64位ID唯一标识。Span还有其他数据信息，比如summary和time。标记事件、SpanID和进度ID。Trace：由一系列Spans组成的树状结构。请求微服务系统的API接口。这个API接口需要调用多个微服务。调用每一个微服务都会生成一个新的Span。此请求生成的所有Span都形成此Trace。Annotation：用于及时记录一个事件，一些核心的annotations用于定义一个请求的开始和结束。这些注解包括以下内容：cs-ClientSent-客户端发送请求，这个注解描述了Span的开始sr-ServerReceived-服务器收到请求并准备开始处理它，如果你从其sr获取网络传输的时间。ss-ServerSent（服务器发送响应）——该注解表示请求处理完成（当请求返回给客户端时），如果ss的时间戳减去sr的时间戳，服务器请求的时间可以是获得。cr-ClientReceived（客户端收到响应）——此时Span结束，如果cr时间戳减去cs时间戳，就可以得到整个请求消耗的时间。侦探入门案例首先，我们启动一个项目，大致如下，我们引入如下依赖>org.springframework.cloudspring-cloud-starter-sleuthorg.projectlomboklombokorg.springframework.bootspring-boot-starter-test测试org.junit.vintagejunit-vintage-engine我们创建一个测试类：packagecom.milo.sleuth.controller；importlombok.extern.slf4j.Slf4j;导入组织.springframework.web.bind.annotation.RequestMapping;importorg.springframework.web.bind.annotation.RestController;@RestController@Slf4jpublicclassExample{@RequestMapping("/")Stringhome(){log.info("Helloworld!");返回"HelloWorld!";}}启动项目后，我们访问：这个时候，我们来看一下日志情况：我们先看看它们是什么意思。第一个是我们的服务名，对应我们配置文件中的spring.application.name第二个是traceId第三个是spanId虽然我们现在可以通过日志文件来识别调用路径，但是好像不是很方便和直观。接下来，我们来了解一下Zipkin。Zipkin引入Zipkin作为分布式跟踪系统。帮助收集解决服务架构中的延迟问题所需的计时数据。功能包括收集和查找这些数据。如果日志文件中有跟踪ID，则可以直接跳转到该跟踪ID。否则，您可以根据服务、操作名称、标签和持续时间等属性进行查询。将为您汇总一些有趣的数据，例如在服务中花费的时间百分比以及操作是否失败。跟踪视图屏幕截图ZipkinUI还提供了一个依赖关系图，显示每个应用程序中跟踪了多少请求。这有助于识别聚合行为，包括错误路径或调用已弃用的服务。需要依赖图屏幕截图来“检测”应用程序以向Zipkin报告跟踪数据。这通常意味着配置跟踪器或检测库。向Zipkin报告数据的最流行方法是通过HTTP或Kafka，尽管存在许多其他选项，例如ApacheActiveMQ、gRPC和RabbitMQ。提供给UI的数据存储在内存中，或持久保存在受支持的后端（例如ApacheCassandra或Elasticsearch）中。Sleuth集成了Zipkin，Zipkin分为两端，一端是Zipkinserver，一端是Zipkinclient。客户端也是一个微服务应用程序。客户端将配置服务器的URL地址。一旦服务之间发生调用，它就会被配置。微服务中的Sleuth监听器监听并生成相应的Trace和Span信息发送给服务端。发送方式有两种，一种是通过RabbitMQ等消息总线发送，另一种是HTTP消息发送。客户端首先，在刚才的依赖文件中，我们添加一个新成员org.springframework.cloudspring-cloud-starter-zipkin然后修改配置文件#应用名称spring:application:name:springcloud-sleuth#应用服务WEB访问端口server:port:9876zipkin:base-url:http://localhost:9411/#服务器地址sender:type:web#Data传输方式，web表示以HTTP报文的形式向服务器发送数据sleuth:sampler:probability:1.0#收集数据百分比，默认0.1（10%）serverZipkin的server是一个可执行的jar文件，我们需要去下载下载地址：https://search.maven.org/remote_content?g=io.zipkin&a=zipkin-server&v=LATEST&c=exec以上地址默认下载最新版本，也可以到以下网址下载指定版本现在我们启动jar包java-jarzipkin-server-2.23.2-exec.jar测试结果接下来我们访问http://localhost:9411/zipkin/，结果如下：环境搭建好了，现在我们测试一下，看看接入Zipkin后，会看到什么效果？我们访问http://localhost:9876/后，在Zipkin控制台点击RunQuery查看，看到如下效果：继续点击show，我们去看看详情。功能强大，执行时间，什么请求方法，请求路径，那个类，那个方法一目了然。由于我们刚刚创建的只是一个非常简单的调用，不足以模拟微服务场景。接下来，让我们看一个更复杂的场景；这里如果我们偷懒的话，我们是不会创建自己的微服务的。我们将使用官方提供的测试用例brave-example。我们将如下所示获取代码。这个项目好像集成了很多技术测试用例。如果我们不明白，我会研究以下内容并运行它让我们测试一下。让我们用idea导入这个项目。看起来像这样。Backend代表后端服务。Frontend代表前端服务。现在，我们首先确保我们的Zipkin服务器没有问题。这个时候你先启动后端服务，然后再启动前端服务，其实执行的是下面的main方法。接下来我们访问http://127.0.0.1:8081/，如下图所示。现在我们去zipkin查看，发现新大陆。开心就show吧，看看里面的情况总结本文主要介绍Sleuth的入门知识，并结合Zipkin可视化调用链路的整体情况。但是Zipkin数据目前是存在内存中的，我们可以接入Elasticsearch等工具进行数据持久化。谢谢大家今天的分享就到这里
