9.3.7 捕获消息传递跟踪

Spring Cloud Sleuth和Zipkin不仅会跟踪HTTP调用，Spring Cloud Sleuth还会向Zipkin发送在服务中注册的入站或出站消息通道上的跟踪数据。

    消息传递可能会在应用程序内引发它自己的性能和延迟问题。这句话的意思是，服务可能无法快速处理队列中的消息，或者可能存在网络延迟问题。在构建基于微服务的应用程序时，我遇到了所有这些情况。

    通过使用Spring Cloud Sleuth和Zipkin，开发人员可以确定何时从队列发布消息以及何时收到消息。除此之外，开发人员还可以查看在队列中接收到消息并进行处理时发生了什么行为。

    正如读者在第8章中记得的，每次添加、更新或删除一条组织记录时，就会生成一条Kafka消息并通过Spring Cloud Stream发布。许可证服务接收消息，并更新用于缓存数据的Redis键值存储。

    现在，我们将删除组织记录，并观察由Spring Cloud Sleuth和Zipkin跟踪的事务。读者可以通过POSTMAN向组织服务发出DELETE http://local-host:5555/api/organization/v1/organizations/e254f8c-c442-4ebe-a82a-e2fc1d1ff78a请求。

    记住，在本章前面，我们了解了如何将跟踪ID添加为HTTP响应首部。我们添加了一个名为tmx-correlation-id的新HTTP响应首部。在我的调用中，这个tmx-correlation-id返回值是5e14cae0d90dc8d4。读者可以通过在Zipkin查询界面右上角的搜索框中输入调用所返回的跟踪ID，来向Zipkin搜索这个特定的跟踪ID。图9-15展示了可以在哪里输入跟踪ID。

 

图9-15　通过在HTTP响应tmx-correlation-id字段中返回的跟踪ID，可以轻松找到要查找的事务

    有了跟踪ID就可以向Zipkin查询特定的事务，并可以查看到删除消息发布到输出消息通道。此消息通道output 用于发布消息到名为orgChangeTopic的主题。图9-16展示了output消息通道及其在Zipkin跟踪中的表现。

图9-16　Spring Cloud Sleuth将自动跟踪Spring消息通道上消息的发布和接收

    通过查询Zipkin并搜索收到的消息可以看到许可证服务收到消息。遗憾的是，Spring Cloud Sleuth不会将已发布消息的跟踪ID传播给消息的消费者。相反，它会生成一个新的跟踪ID。但是，我们可以向Zipkin服务器查询所有许可证服务的事务，并通过最新消息对事务进行排序。

 

图9-17展示了这个查询的结果。

图9-17　寻找接收到Kafka消息的许可证服务调用

    既然已经找到目标许可证服务的事务，我们就可以深入了解这个事务。图9-18展示了这次深入探查的结果。

图9-18　使用Zipkin可以看到组织服务发布的Kafka消息

 

到目前为止，我们已经使用Zipkin来跟踪服务中的HTTP和消息传递调用。但是，如果要对未由Zipkin 检测的第三方服务执行跟踪，那该怎么办呢？例如，如果想要获取对Redis或PostgresSQL调用的特定跟踪和计时信息，该怎么办呢？幸运的是，Spring Cloud Sleuth和Zipkin允许开发人员为事务添加自定义跨度，以便跟踪与这些第三方调用相关的执行时间。