DistributedTracing允许您在分布式系统中跟踪请求。本文将向您介绍如何使用SpringCloudSleuth和Zipkin来做到这一点。对于一个包罗万象的大型应用程序（我们通常称其为单体应用程序），很容易跟踪应用程序内的传入请求。我们可以跟踪日志并弄清楚请求是如何处理的。除了应用程序日志本身，我们不需要查看任何其他内容。随着时间的推移，随着代码库规模的增长，单体应用程序变得难以扩展、处理大量请求以及向客户提供新功能。这导致将单体架构分解为微服务，这有助于扩展单个组件并促进更快的交付。但并非所有发光的都是金子，对吧？微服务也是如此。我们将整个整体拆分为微服务，由一组本地函数调用处理的每个请求现在都被对一组分布式服务的调用所取代。这样我们就失去了跟踪请求之类的东西，而这些在单体应用程序中很容易完成。现在，要跟踪每个请求，我们必须查看每个服务的日志，而且很难关联起来。因此，在分布式系统的情况下，分布式跟踪的概念有助于跟踪请求。什么是分布式跟踪？分布式跟踪是一种机制，通过它我们可以在整个分布式系统中跟踪特定请求。它使我们能够跟踪请求如何从一个系统进展到另一个系统，从而满足用户的请求。分布式跟踪的关键概念分布式跟踪包括两个主要概念：traceidspannumbertraceid用于跟踪传入请求并跨所有组合服务跟踪它以完成请求。Spanid跨越服务调用以跟踪收到的每个请求和发送的响应。让我们看一下图表。传入请求没有任何跟踪ID。拦截调用的第一个服务生成跟踪ID“ID1”及其跨度ID“A”。spanid"B"涵盖从服务器一上的客户端发送请求到服务器二接收、处理并发出响应的时间。SpringCloudSleuth的SpringBoot示例让我们创建一个集成了SpringCloudSleuth的应用程序。首先，让我们访问https://start.spring.io/并创建一个依赖“SpringWeb”和“SpringCloudSleuth”的应用程序。现在让我们创建一个带有两个请求映射的简单控制器。publicclassController{privatestaticfinalLoggerlogger=LoggerFactory.getLogger(Controller.class);私有RestTemplaterestTemplate；@Value("${spring.application.name}")privateStringapplicationName;公共控制器（RestTemplaterestTemplate）{这个。休息模板=休息模板；}@GetMapping("/path1")publicResponseEntitypath1(){logger.info("Requestat{}forrequest/path1",applicationName);Stringresponse=restTemplate.getForObject("http://localhost:8090/service/path2",String.class);returnResponseEntity.ok("来自/path1的响应+"+response);}@GetMapping("/path2")publicResponseEntitypath2(){logger.info("Requestat{}at/path2",applicationName);returnResponseEntity.ok("responsefrom/path2");}在这里，我创建了两条路径，Path1调用Path2固定端口8090。这里的想法是运行同一个应用程序的两个独立实例。现在为了允许侦探将标头注入传出请求，我们需要将RestTemplate作为bean注入而不是直接初始化它。这将允许Sleuth向RestTemplate添加一个拦截器，以将带有跟踪ID和跨度ID的标头注入到传出请求中。@BeanpublicRestTemplaterestTemplate(RestTemplateBuilderbuilder){returnbuilder.build();现在，让我们启动两个实例。为此，首先，构建应用程序，mvncleanverify，然后运行以下命令启动“服务1”。java-jar\target/Distributed-Service-0.0.1-SNAPSHOT.jar\--spring.application.name=Service-1\--server.port=8080然后在不同的终端运行“服务2”，如下如图：java-jar\target/Distributed-Service-0.0.1-SNAPSHOT.jar\--spring.application.name=Service-2\--server.port=8090应用启动后，调用“Service1”，/path1看起来像这样：curl-ihttp://localhost:8080/service/path1现在让我们看看“服务1”的日志。INFO[Service-1,222f3b00a283c75c,222f3b00a283c75c]41114---[nio-8080-exec-1]c.a.p.distributedservice.Controller：Service-1的传入请求请求/path1日志包含方括号，包含三个部分[ServiceName,Trace编号，跨度编号]。对于第一个传入的请求，由于没有传入的traceid，spanid与traceid相同。查看“服务2”的??日志，我们看到我们有一个新的跨度ID用于此请求。INFO[Service-2,222f3b00a283c75c,13194db963293a22]41052---[nio-8090-exec-1]c.a.p.distributedservice.Controller:Service-2at/path2的传入请求我拦截了从“Service-1”到“Service-”的发送2"请求，发现传出请求中已存在以下标头。x-b3-traceid:"222f3b00a283c75c",x-b3-spanid:"13194db963293a22",x-b3-parentspanid:"222f3b00a283c75c这里我们看到下一个操作的span（调用"Service2"）已经注入了标头。当客户端发出请求时，这些由“服务1”注入。这意味着下一次调用“服务2”的??跨度已经从“服务1”的客户端开始。在上面显示的标头中，“Service1”的spanid现在是下一个span的父spanid。为了让事情更容易理解，我们可以使用一个名为Zipkin的拦截器工具可视化跟踪。使用Zipkin可视化跟踪将要与Zipkin集成
