分布式跟蹤允許您跟蹤分布式系統中的請求。本文通過了解如何使用 Spring Cloud Sleuth 和 Zipkin 來做到這一點。

對于一個做所有事情的大型應用程序(我們通常將其稱為單體應用程序)，跟蹤應用程序內的傳入請求很容易。我們可以跟蹤日志，然后弄清楚請求是如何處理的。除了應用程序日志本身之外，我們無需查看其他任何內容。

隨著時間的推移，單體應用程序變得難以擴展，難以處理大量請求以及隨著代碼庫規模的不斷擴大向客戶提供新功能。這導致將單體架構分解為微服務，這有助于擴展單個組件并有助于更快地交付。

但并非所有閃耀的都是黃金，對吧?微服務也是如此。我們將整個單體系統拆分為微服務，由一組本地函數調用處理的每個請求現在都被調用一組分布式服務所取代。這樣一來，我們就失去了追蹤在單體應用中很容易完成的請求之類的事情。現在，要跟蹤每個請求，我們必須查看每個服務的日志，并且很難關聯。

因此，在分布式系統的情況下，分布式跟蹤的概念有助于跟蹤請求。

什么是分布式跟蹤?

分布式跟蹤是一種機制，我們可以使用它跟蹤整個分布式系統中的特定請求。它允許我們跟蹤請求如何從一個系統進展到另一個系統，從而完成用戶的請求。

分布式跟蹤的關鍵概念

分布式跟蹤包含兩個主要概念：

• 跟蹤 ID
• 跨度編號

跟蹤 id 用于跟蹤傳入請求并在所有組合服務中跟蹤它以滿足請求。Span id 跨越服務調用以跟蹤接收到的每個請求和發出的響應。

讓我們看一下圖表。

傳入的請求沒有任何跟蹤 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 客戶端依賴項。

<dependency> <groupId>org.springframework.cloudgroupId> <artifactId>spring-cloud-sleuth-zipkinartifactId> dependency>

添加此依賴項后，Zipkin 客戶端默認將跟蹤發送到 Zipkin 服務器的 9411 端口。讓我們使用其 docker 映像啟動 Zipkin 服務器。我為此創建了一個簡單的 docker-compose 文件。

version: "3.1" services: zipkin: image: openzipkin/zipkin:2 ports: - "9411:9411"

我們現在可以使用docker-compose up命令啟動服務器。然后，您可以在以下位置訪問 UIhttp://localhost:9411/

由于我們使用的是默認端口，我們不需要指定任何屬性，但是如果您打算使用不同的端口，則需要添加以下屬性。

spring: zipkin: baseUrl: http://localhost:9411

完成后，讓我們使用上面相同的命令啟動兩個應用程序。在向路徑中的“服務 1”發出請求時，/path1我們會得到以下跟蹤。

這里顯示了兩個服務的跨度。我們可以通過查看跨度來更深入地挖掘。

“服務 1”的跨度是一個正常的跨度，涵蓋了它接收到返回響應的請求。有趣的是第二個跨度。

在此，跨度中有四個點。

• 第一點是指來自“服務1”的客戶端何時開始請求。
• 第二點是“服務 2”開始處理請求的時間。
• 第三點是“Server 1”上的客戶端完成接收響應的時間。
• 最后，“服務器 2”完成的最后一點。

因此，我們了解了如何將分布式跟蹤與 Spring Cloud Sleuth 集成，并使用 Zipkin 可視化跟蹤。

原文地址：https://www.toutiao.com/a7061504642995290657/