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