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

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

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

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

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

什么是分布式跟蹤?

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

分布式跟蹤的關(guān)鍵概念

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

• 跟蹤 ID
• 跨度編號

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

讓我們看一下圖表。

傳入的請求沒有任何跟蹤 ID。攔截調(diào)用的第一個服務會生成跟蹤 ID“ID1”及其跨度 ID“A”。span id“B”涵蓋了從服務器一的客戶端發(fā)出請求到服務器二接收、處理并發(fā)出響應的時間。

帶有 Spring Cloud Sleuth 的 Spring Boot 示例

讓我們創(chuàng)建一個集成了 Spring Cloud Sleuth 的應用程序。首先，讓我們訪問https://start.spring.io/并使用依賴項“Spring Web”和“Spring Cloud Sleuth”創(chuàng)建一個應用程序。

現(xiàn)在讓我們創(chuàng)建一個帶有兩個請求映射的簡單控制器。

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 ");
}

在這里，我創(chuàng)建了兩條路徑，Path1調(diào)用Path2固定端口 8090。這里的想法是運行同一應用程序的兩個單獨實例。

現(xiàn)在為了允許偵探將標頭注入到傳出請求中，我們需要將 RestTemplate 作為 bean 注入，而不是直接初始化它。這將允許偵探向 RestTemplate 添加一個攔截器，以將帶有跟蹤 id 和跨度 id 的標頭注入到傳出請求中。

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

現(xiàn)在，讓我們啟動兩個實例。為此，首先，構(gòu)建應用程序，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

應用程序啟動后，調(diào)用“Service 1”，/path1如下所示：

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

現(xiàn)在讓我們看看“服務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”的日志，我們看到我們?yōu)榇苏埱笥幸粋€新的 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”發(fā)送到“服務 2”的請求，并發(fā)現(xiàn)傳出的請求中已經(jīng)存在以下標頭。

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

在這里，我們看到下一個操作(對“服務 2”的調(diào)用)的跨度已經(jīng)注入到標頭中。這些是在客戶端發(fā)出請求時由“服務 1”注入的。這意味著下一次調(diào)用“服務 2”的跨度已經(jīng)從“服務 1”的客戶端開始。在上面顯示的標題中，“服務 1”的 span id 現(xiàn)在是下一個 span 的父 span id。

為了讓事情更容易理解，我們可以使用名為Zipkin的攔截器工具直觀地查看跟蹤。

使用 Zipkin 可視化跟蹤

要將 Zipkin 與應用程序集成，我們需要向應用程序添加 Zipkin 客戶端依賴項。

<dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-sleuth-zipkin</artifactId>
</dependency>

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

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

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

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

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

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

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

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

在此，跨度中有四個點。

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

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