Spring|Spring Cloud Sleuth 和 Zipkin 进行分布式跟踪使用指南 SpringCloudSleuth和Zipkin进行分布式

分布式跟踪允许您跟踪分布式系统中的请求。本文通过了解如何使用 Spring Cloud Sleuth 和 Zipkin 来做到这一点。

文章图片

【Spring|Spring Cloud Sleuth 和 Zipkin 进行分布式跟踪使用指南】对于一个做所有事情的大型应用程序（我们通常将其称为单体应用程序），跟踪应用程序内的传入请求很容易。我们可以跟踪日志，然后弄清楚请求是如何处理的。除了应用程序日志本身之外，我们无需查看其他任何内容。
随着时间的推移，单体应用程序变得难以扩展，难以处理大量请求以及随着代码库规模的不断扩大向客户提供新功能。这导致将单体架构分解为微服务，这有助于扩展单个组件并有助于更快地交付。
但并非所有闪耀的都是黄金，对吧？微服务也是如此。我们将整个单体系统拆分为微服务，由一组本地函数调用处理的每个请求现在都被调用一组分布式服务所取代。这样一来，我们就失去了追踪在单体应用中很容易完成的请求之类的事情。现在，要跟踪每个请求，我们必须查看每个服务的日志，并且很难关联。
因此，在分布式系统的情况下，分布式跟踪的概念有助于跟踪请求。
什么是分布式跟踪？分布式跟踪是一种机制，我们可以使用它跟踪整个分布式系统中的特定请求。它允许我们跟踪请求如何从一个系统进展到另一个系统，从而完成用户的请求。
分布式跟踪的关键概念分布式跟踪包含两个主要概念：

跟踪 ID
跨度编号

跟踪 id 用于跟踪传入请求并在所有组合服务中跟踪它以满足请求。Span id 跨越服务调用以跟踪接收到的每个请求和发出的响应。
让我们看一下图表。

Spring|Spring Cloud Sleuth 和 Zipkin 进行分布式跟踪使用指南

文章图片

传入的请求没有任何跟踪 ID。拦截调用的第一个服务会生成跟踪 ID“ID1”及其跨度 ID“A”。span id“B”涵盖了从服务器一的客户端发出请求到服务器二接收、处理并发出响应的时间。
带有 Spring Cloud Sleuth 的 Spring Boot 示例让我们创建一个集成了 Spring Cloud Sleuth 的应用程序。首先，让我们访问https://start.spring.io/并使用依赖项“Spring Web”和“Spring Cloud Sleuth”创建一个应用程序。
现在让我们创建一个带有两个请求映射的简单控制器。

public class Controller { private static final Logger logger = LoggerFactory.getLogger(Controller.class); private RestTemplate restTemplate; @Value("${spring.application.name}") private String applicationName; public Controller(RestTemplate restTemplate) { this.restTemplate = restTemplate; } @GetMapping("/path1") public ResponseEntity path1() {logger.info("Request at {} for request /path1 ", applicationName); String response = restTemplate.getForObject("http://localhost:8090/service/path2", String.class); return ResponseEntity.ok("response from /path1 + "+ response); }@GetMapping("/path2") public ResponseEntity path2(){ logger.info("Request at {} at /path2", applicationName); return ResponseEntity.ok("response from /path2 "); }

在这里，我创建了两条路径，Path1调用Path2固定端口 8090。这里的想法是运行同一应用程序的两个单独实例。
现在为了允许侦探将标头注入到传出请求中，我们需要将 RestTemplate 作为 bean 注入，而不是直接初始化它。这将允许侦探向 RestTemplate 添加一个拦截器，以将带有跟踪 id 和跨度 id 的标头注入到传出请求中。

@Bean public RestTemplate restTemplate(RestTemplateBuilder builder) { return builder.build(); }

现在，让我们启动两个实例。为此，首先，构建应用程序，mvn clean verify然后运行以下命令来启动“服务 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

应用程序启动后，调用“Service 1”，/path1如下所示：

curl -i http://localhost:8080/service/path1

现在让我们看看“服务1”的日志。

INFO [Service-1,222f3b00a283c75c,222f3b00a283c75c] 41114 --- [nio-8080-exec-1] c.a.p.distributedservice.Controller: Incoming request at Service-1 for request /path1

日志包含方括号，其中包含三个部分 [Service Name, Trace Id, Span Id]。对于第一个传入的请求，由于没有传入的trace id，span id 与trace id 相同。
查看“服务 2”的?日志，我们看到我们为此请求有一个新的 span id。

INFO [Service-2,222f3b00a283c75c,13194db963293a22] 41052 --- [nio-8090-exec-1] c.a.p.distributedservice.Controller: Incoming request at Service-2 at /path2

我截获了从“服务 1”发送到“服务 2”的??请求，并发现传出的请求中已经存在以下标头。

x-b3-traceid:"222f3b00a283c75c", x-b3-spanid:"13194db963293a22", x-b3-parentspanid:"222f3b00a283c75c

在这里，我们看到下一个操作（对“服务 2”的??调用）的跨度已经注入到标头中。这些是在客户端发出请求时由“服务 1”注入的。这意味着下一次调用“服务 2”的??跨度已经从“服务 1”的客户端开始。在上面显示的标题中，“服务 1”的 span id 现在是下一个 span 的父 span id。
为了让事情更容易理解，我们可以使用名为Zipkin的拦截器工具直观地查看跟踪。
使用 Zipkin 可视化跟踪要将 Zipkin 与应用程序集成，我们需要向应用程序添加 Zipkin 客户端依赖项。