本章主要内容
使用Spring Cloud Sleuth将跟踪信息注入服务调用
使用日志聚合来查看分布式事务的日志
通过日志聚合工具进行查询
在跨多个微服务调用时，使用OpenZipkin直观地理解用户的事务
使用Spring Cloud Sleuth和Zipkin定制跟踪信息
微服务架构是一种强大的设计范型，可以将复杂的单体软件系统分解为更小、更易于管理的部分。这些可管理的部分可以独立构建和部署。然而，这种灵活性是要付出代价的，那就是复杂性。因为微服务本质上是分布式的，所以要调试问题出现的地方可能会让人抓狂。服务的分布式特性意味着必须在多个服务、物理机器和不同的数据存储之间跟踪一个或多个事务，然后试图拼凑出究竟发生了什么。
本章列出了可能实现分布式调试的几种技术。在这一章中，我们将关注以下内容。
使用关联ID将跨多个服务的事务链接在一起。
将来自多个服务的日志数据聚合为一个可搜索的源。
可视化跨多个服务的用户事务流，并理解事务每个部分的性能特征。
为了完成这3件事，我们将使用以下3种不同的技术。
Spring Cloud Sleuth——Spring Cloud Sleuth是一个Spring Cloud项目，它将关联ID装备到HTTP调用上，并将生成的跟踪数据提供给OpenZipkin的钩子。Spring Cloud Sleuth通过添加过滤器并与其他Spring组件进行交互，将生成的关联ID传递到所有系统调用。
Papertrail——Papertrail是一种基于云的服务（基于免费增值），允许开发人员将来自多个源的日志数据聚合到单个可搜索的数据库中。开发人员可以为日志聚合选择的解决方案包括内部部署解决方案、基于云解决方案、开源解决方案和商业解决方案。本章稍后将介绍几种备选方案。
Zipkin——Zipkin是一种开源数据可视化工具，可以显示跨多个服务的事务流。Zipkin 允许开发人员将事务分解到它的组件块中，并可视化地识别可能存在性能热点的位置。
要开始本章的内容, 我们从最简单的跟踪工具——关联ID开始。
注意
本章的部分内容依赖于第6章中介绍的内容（特别是Zuul的前置过滤器、路由过滤器和后置过滤器）。如果读者还没有读过第6章，建议在阅读这一章之前先读一读。
9.1 Spring Cloud Sleuth与关联ID
在第5章和第6章中，我们介绍了关联ID的概念。关联ID是一个随机生成的、唯一的数字或字符串，它在事务启动时分配给一个事务。当事务流过多个服务时，关联ID从一个服务调用传播到另一个服务调用。在第6章的上下文中，我们使用Zuul过滤器检查了所有传入的HTTP请求，并且在关联ID不存在的情况下注入关联ID。
一旦提供了关联ID，就可以在每个服务上使用自定义的Spring HTTP过滤器，将传入的变量映射到自定义的UserContext对象。有了UserContext对象，现在可以手动地将关联ID添加到日志语句中，或者通过少量工作将关联ID直接添加到Spring的映射诊断上下文（Mapped Diagnostic Context，MDC）中，从而确保将关联ID添加到任何日志语句中。我们还编写了一个Spring拦截器，该拦截器通过向出站调用添加关联ID到HTTP首部中，确保来自服务的所有HTTP调用都会传播关联ID。
对了，我们必须施展Spring和Hystrix的魔法，以确保持有关联ID的父线程的线程上下文被正确地传播到Hystrix。
在最后，这些数量众多的基础设施都是为了某些你希望只有在问题发生时才查看的东西而设置的（使用关联ID来跟踪事务中发生了什么）。
幸运的是，Spring Cloud Sleuth能够为开发人员管理这些代码基础设施并处理复杂的工作。通过添加Spring Cloud Sleuth到Spring微服务中，开发人员可以：
透明地创建并注入一个关联ID到服务调用中（如果关联ID不存在）；
管理关联ID到出站服务调用的传播，以便将事务的关联ID自动添加到出站调用中；
将关联信息添加到Spring的MDC日志记录，以便生成的关联ID由Spring Boot默认的SL4J和Logback实现自动记录；
（可选）将服务调用中的跟踪信息发布到Zipkin分布式跟踪平台。
注意
有了Spring Cloud Sleuth，如果使用Spring Boot的日志记录实现，关联ID就会自动添加到微服务的日志语句中。
让我们继续，将Spring Cloud Sleuth添加到许可证服务和组织服务中。