9.3 使用Open Zipkin進行分佈式跟蹤

 

    具備關聯ID的統一日誌記錄平臺是一個強大的調試工具。可是，在本章的剩餘部分中，咱們將再也不關注如何跟蹤日誌條目，而是關注如何跨不一樣微服務可視化事務流。一張乾淨簡潔的圖片比一百萬條日誌條目有用。

分佈式跟蹤涉及提供一張可視化的圖片，說明事務如何流經不一樣的微服務。分佈式跟蹤工具還將對單個微服務響應時間做出粗略的估計。可是，分佈式跟蹤工具不該該與成熟的應用程序性能管理（Application Performance Management，APM）包混淆。這些包能夠爲服務中的實際代碼提供開箱即用的低級性能數據，除了提供響應時間，它還能提供其餘性能數據，如內存利用率、CPU利用率和I/O利用率。

    這就是Spring Cloud Sleuth和OpenZipkin（也稱爲Zipkin）項目的亮點。Zipkin是一個分佈式跟蹤平臺，可用於跟蹤跨多個服務調用的事務。Zipkin容許開發人員以圖形方式查看事務佔用的時間量，並分解在調用中涉及的每一個微服務所用的時間。在微服務架構中，Zipkin是識別性能問題的寶貴工具。

    創建Spring Cloud Sleuth和Zipkin涉及4項操做：

    將Spring Cloud Sleuth和Zipkin JAR文件添加到捕獲跟蹤數據的服務中；

    在每一個服務中配置Spring屬性以指向收集跟蹤數據的Zipkin服務器；

    安裝和配置Zipkin服務器以收集數據；

    定義每一個客戶端所使用的採樣策略，便於向Zipkin發送跟蹤信息。

    

9.3.1　添加Spring Cloud Sleuth和Zipkin依賴項

 

到目前爲止，咱們已經將兩個Maven依賴項包含到Zuul服務、許可證服務以及組織服務中。這些JAR文件是 spring-cloud-starter-sleuth和spring-cloud-sleuth-core依賴項。spring-cloud-starter-sleuth依賴項用於包含在服務中啓用Spring Cloud Sleuth所需的基本Spring Cloud Sleuth庫。當開發人員必需要以編程方式與Spring Cloud Sleuth進行交互時，就須要使用 spring-cloud-sleuth-core依賴項（本章後面將再次使用它）。

    要與Zipkin集成，須要添加第二個Maven依賴項，名爲spring-cloud-sleuth-zipkin。代碼清單9-3展現了添加spring-cloud-sleuth-zipkin依賴項後，在Zuul、許可證以及組織服務中應該存在的Maven條目。

    

代碼清單9-3　客戶端的Spring Cloud Sleuth和Zipkin依賴項

    

<dependency>   

<groupId>org.springframework.cloud</groupId>   

<artifactId>spring-cloud-starter-sleuth</artifactId> 

</dependency> 

<dependency>   

<groupId>org.springframework.cloud</groupId>   

<artifactId>spring-cloud-sleuth-zipkin</artifactId> 

</dependency>

    

9.3.2　配置服務以指向Zipkin

    有了JAR文件，接下來就須要配置想要與Zipkin進行通訊的每一項服務。這項任務能夠經過設置一個Spring屬性spring.zipkin.baseUrl來完成，該屬性定義了用於與Zipkin通訊的URL，它設置在每一個服務的application.yml屬性文件中。

    

注意

    

spring.zipkin.baseUrl也能夠做爲Spring Cloud Config中的屬性進行外部化。

    

在每一個服務的application.yml文件中，將該值設置爲 http://localhost:9411。可是，在運行時，我使用在每一個服務的Docker配置文件（docker/common/docker-compose.yml）上傳遞的ZIPKIN_URI（ http://zipkin:9411）變量來覆蓋這個值。

    

Zipkin、RabbitMQ與Kafka

    Zipkin確實有能力經過RabbitMQ或Kafka將其跟蹤數據發送到Zipkin服務器。從功能的角度來看，無論使用HTTP、RabbitMQ仍是Kafka，Zipkin的行爲沒有任何差別。經過使用HTTP跟蹤，Zipkin使用異步線程發送性能數據。另外，使用RabbitMQ或Kafka來收集跟蹤數據的主要優點是，若是Zipkin服務器關閉，任何發送給Zipkin的跟蹤信息都將「排隊」，直到Zipkin可以收集到數據。

    Spring Cloud Sleuth經過RabbitMQ和Kafka向Zipkin發送數據的配置在Spring Cloud Sleuth文檔中有介紹，所以本章將再也不贅述。

    9.3.3　安裝和配置Zipkin服務器

    要使用Zipkin，首先須要按照本書屢次所作的那樣創建一個Spring Boot項目（本章的項目名爲 zipkinsvr）。接下來，須要向zipkinsvr/pom.xml文件添加兩個JAR依賴項。代碼清單9-4展現了這兩個JAR依賴項。

 

代碼清單9-4　Zipkin服務所需的JAR依賴項

    

<dependency>   

<groupId>io.zipkin.java</groupId>   

<artifactId>zipkin-server</artifactId>　　⇽---　這個依賴項包含用於建立Zipkin服務器所需的核心類 

</dependency>  

<dependency>   

<groupId>io.zipkin.java</groupId>   

<artifactId>zipkin-autoconfigure-ui</artifactId>　　⇽---　這個依賴項包含用於運行Zipkin服務器的UI部分所需的核心類 </dependency>

    

選擇@EnableZipkinServer仍是@EnableZipkinStreamServer

    

關於上述JAR依賴項，有一件事須要注意，那就是它們不是基於Spring Cloud的依賴項。雖然Zipkin是一個基於Spring Boot的項目，可是@EnableZipkinServer並非一個Spring Cloud註解，它是Zipkin項目的一部分。這一般會讓Spring Cloud Sleuth和Zipkin的新手混淆，由於Spring Cloud團隊確實編寫了@EnableZipkinStreamServer註解做爲Spring Cloud Sleuth的一部分，它簡化了Zipkin與RabbitMQ和Kafka的使用。

    

我選擇使用@EnableZipkinServer是由於對本章來講它建立簡單。使用@EnableZipkinStreamServer須要建立和配置正在跟蹤的服務以發佈消息到RabbitMQ或Kafka，此外，還須要設置和配置Zipkin服務器來監聽RabbitMQ或Kafka，以此來跟蹤數據。@EnableZipkinStreamServer註解的優勢是，即便Zipkin服務器不可用，也能夠繼續收集跟蹤數據。這是由於跟蹤消息將在消息隊列中累積跟蹤數據，直到Zipkin服務器可用於處理消息記錄。若是使用了@EnableZipkinServer註解，而Zipkin服務器不可用，那麼服務發送給Zipkin的跟蹤數據將會丟失。

 

在定義完JAR依賴項以後，如今須要將@EnableZipkinServer註解添加到Zipkin服務引導類中。這個類位於zipkinsvr/src/main/java/com/thoughtmechanix/zipkinsvr/ZipkinServerApplication.java中。代碼清單9-5展現了引導類的代碼。

    

代碼清單9-5　構建Zipkin服務器引導類

package com.thoughtmechanix.zipkinsvr;

 

import org.springframework.boot.SpringApplication;

import org.springframework.boot.autoconfigure.SpringBootApplication;

import zipkin.server.EnableZipkinServer;

⇽---　@EnableZipkinServer 容許快速啓動Zipkin做爲Spring Boot項目

@SpringBootApplication

@EnableZipkinServer

public class ZipkinServerApplication {

    public static void main(String[] args) {

        SpringApplication.run(ZipkinServerApplication.class, args);

    }

}

    

在代碼清單9-5中要注意的關鍵點是@EnableZipkinServer註解的使用。這個註解可以啓動這個Spring Boot服務做爲一個Zipkin服務器。此時，讀者能夠構建、編譯和啓動Zipkin服務器，做爲本章的Docker容器之一。

    

運行Zipkin服務器只須要不多的配置。在運行Zipkin服務器時，惟一須要配置的東西，就是Zipkin存儲來自服務的跟蹤數據的後端數據存儲。Zipkin支持4種不一樣的後端數據存儲。這些數據存儲是：

    （1）內存數據；

    （2）MySQL；

    （3）Cassandra；

    （4）Elasticsearch。

    在默認狀況下，Zipkin使用內存數據存儲來存儲跟蹤數據。Zipkin團隊建議不要在生產系統中使用內存數據庫。內存數據庫只能容納有限的數據，而且在Zipkin服務器關閉或丟失時，數據就會丟失。

    

注意

    對於本書來說，咱們將使用Zipkin的內存數據存儲。配置Zipkin中使用的各個數據存儲超出了本書的範圍，可是，若是讀者對這個主題感興趣，能夠在Zipkin GitHub存儲庫中查閱更多信息。

 

9.3.4　設置跟蹤級別

    到目前爲止，咱們已經配置了要與Zipkin服務器通訊的客戶端，而且已經配置完Zipkin服務器準備運行。在開始使用Zipkin以前，咱們還須要再作一件事情，那就是定義每一個服務應該向Zipkin寫入數據的頻率。

    在默認狀況下，Zipkin只會將全部事務的10%寫入Zipkin服務器。能夠經過在每個向Zipkin發送數據的服務上設置一個Spring屬性來控制事務採樣。這個屬性叫spring.sleuth.sampler.percentage，它的值介於0和1之間。

    值爲0表示Spring Cloud Sleuth不會發送任何事務數據。

    值爲0.5表示Spring Cloud Sleuth將發送全部事務的50%。

    對於本章來說，咱們將爲全部服務發送跟蹤信息。要作到這一點，咱們能夠設置spring.sleuth.sampler.percentage的值，也可使用AlwaysSampler替換Spring Cloud Sleuth中使用的默認Sampler類。AlwaysSampler能夠做爲Spring Bean注入應用程序中。例如，許可證服務在licensing-service/src/main/java/com/thoughtmechanix/licenses/Application.java 中將AlwaysSampler定義爲Spring Bean。

    

@Bean 

public Sampler defaultSampler() { return new AlwaysSampler();}

    

Zuul服務、許可證服務和組織服務都定義了AlwaysSampler，所以在本章中，全部的事務都會被Zipkin跟蹤。

spring cloud zipkin elk