sleuth+zipkin 面试

https://blog.csdn.net/JFENG14/article/details/140209646

面试的时候可以这么说。

总所周知，微服务项目的服务实例数量比较多，服务间的调用比较复杂。

这个时候，如何

快速发现问题

分析链路的每个节点的耗时情况，进而提升系统的性能。

这个时候我们就需要使用分布式链路追踪技术，我比较熟悉的是 Sleuth+zipkin。

​ 分布式链路追踪（Distributed Tracing），就是将一次分布式请求还原成调用链路，进行日志记录，性能监控并将一次分布式请求的调用情况集中展示。比如各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态等等。

sleuth底层：

为了实现请求跟踪，当请求到达分布式系统的入口端点时，只需要服务跟踪框架为该请求创建一个唯一的标识（即TraceId），同时在分布式系统内部流转的时候，框架始终保持传递该唯一值，直到整个请求的返回。那么我们就可以使用该唯一标识将所有的请求串联起来，形成一条完整的请求链路。

Span 代表了一组基本的工作单元。为了统计各处理单元的延迟，当请求到达各个服务组件的时候，也通过一个唯一标识（SpanId）来标记它的开始、具体过程和结束。通过SpanId的开始和结束时间戳，就能统计该span的调用时间，除此之外，我们还可以获取如事件的名称。请求信息等元数据。

当然，我们项目中引入sleuth也比较简单，只需要在pom.xml文件中添加sleuth的依赖，然后我们在微服务调用的过程中，我们就能够在控制台看到每个节点的耗时情况了。但是这种方式不直观，于是我们就引入了zipkin可视化。

上图展示了 Zipkin 的基础架构，它主要由 4 个核心组件构成：
Collector：收集器组件，它主要用于处理从外部系统发送过来的跟踪信息，将这些信息转换为 Zipkin内部处理的 Span 格式，以支持后续的存储、分析、展示等功能。
Storage：存储组件，它主要对处理收集器接收到的跟踪信息，默认会将这些信息存储在内存中，我们也可以修改此存储策略，通过使用其他存储组件将跟踪信息存储到数据库中。
RESTful API：API 组件，它主要用来提供外部访问接口。比如给客户端展示跟踪信息，或是外接系统访问以实现监控等。
Web UI：UI 组件， 基于API组件实现的上层应用。通过UI组件用户可以方便而有直观地查询和分析跟踪信息。

zipkin的收集器组件会监听sleuth上传过来的链路信息，并使用它的UI界面进行展示。

当然，zipkin它也支持外部存储，我们可以把这些信息存储在数据库MySQL中，或者是elasticsearch中。