学习笔记—微服务—技术栈实践(8)—链路追踪

为什么需要链路追踪

  前文中有提到，微服务会把项目拆分，导致系统服务间的调用链路变得相当复杂，那么一个前端请求可能最终需要调用多个后端服务才能实现，当前端发起一个请求后，调用链路可能会非常复杂，比如A->B->C->D->B->C->O这样一条长长的链路才能获得所需要的调用，当整个请求出现不可用的时候，怎么知道是在哪一个服务端引发的问题呢？

  很难确定，因此，跟进一个请求到底有哪些服务参与，参与的顺序怎么样，是非常关键的。

  这也是为什么需要分布式链路追踪系统的原因。

链路追踪技术选型

  链路追踪其实已经不算是新兴的概念和技术了，可以使用的组件非常多，比如sleuth、sky walking、zipkin、阿里鹰眼等等。

 &emsp这些组件有一个共同的名字就是APM工具，Application Performance Management，换言之就是应用性能监控工具。

  于此，介绍两种解决方案，分别为zipkin+sleuth和skywalking。

zipkin+sleuth

什么是Zipkin和Sleuth

  Zipkin 和 Sleuth 是分布式追踪（Distributed Tracing）技术栈中的两个关键组件，通常用于监控微服务系统中跨服务的请求调用链。它们能够帮助开发者追踪请求在多个微服务中的流转路径，进而分析性能瓶颈和故障。它们的组合在 Spring Cloud 微服务架构中使用广泛。

  Zipkin 是一个开源的分布式追踪系统，最初由 Twitter 开发。它负责收集、存储、分析和展示分布式系统中的调用链信息。通过收集来自不同微服务的追踪数据，Zipkin 可以帮助你了解一个请求的完整生命周期，精确地找到延迟较高的服务。

  Sleuth 是 Spring Cloud 提供的一个分布式追踪解决方案，它为 Spring 应用提供了透明的追踪支持。Sleuth 与 Zipkin 搭配使用时，能够自动为请求生成追踪信息，并将这些追踪数据发送到 Zipkin。

  换言之，zipkin负责收集和