具有关联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