公司动态
Sleuth--链路追踪
1. 为什么需要链路追踪核心痛点在微服务架构中一个用户请求往往需要经过多个服务比如网关→订单→商品→库存。当请求变慢或出错时我们面临的核心问题是问题定位难日志分散在不同服务器的不同服务里很难快速找到是哪一步出了问题。依赖梳理难不清楚服务间的调用关系是否合理是否有循环依赖。性能分析难无法直观看到每个服务环节的耗时难以找到性能瓶颈。分布式链路追踪就是为了解决这些问题它能把一次请求经过的所有服务串联起来形成一个完整的调用链视图。2. Sleuth核心术语理解链路数据模型Sleuth是Spring Cloud提供的链路追踪解决方案它会在日志中注入追踪信息。理解这三个核心概念是关键Trace追踪代表一次完整的请求链路。从用户发起请求到最终收到响应这整个过程中经过的所有服务都属于同一个Trace。它有一个全局唯一的ID即TraceId。Span跨度代表链路中的一个基本工作单元。比如订单服务调用商品服务这个远程调用RPC过程就是一个Span。每个Span也有自己的唯一ID即SpanId。一个Trace由多个Span组成它们通过ParentId形成树状结构。Annotation注解用来标记一个Span生命周期中的关键事件主要用于计算耗时cs (Client Send)客户端发起请求标志着Span开始。sr (Server Receive)服务端收到请求。sr - cs 网络延迟。ss (Server Send)服务端处理完成准备返回响应。ss - sr 服务端处理时间。cr (Client Receive)客户端收到响应标志着Span结束。cr - sr 整个请求的总时间。3. 准备工作实验环境搭建这是为了排除干扰搭建一个干净的测试环境我帮你解释一下每一步的意图注释掉网关的自定义断言/过滤器防止自定义逻辑对请求链路产生干扰让测试结果更纯粹。采用最简单的网关配置直接使用服务名作为请求前缀如/order-serv/...这是Spring Cloud Gateway配合服务发现如Nacos的默认路由方式简单直观。在商品服务中加入Thread.sleep(5000)这是人为制造一个性能瓶颈。这样在Zipkin的UI界面上就能清晰地看到“商品服务”这个Span耗时5秒直观展示链路追踪对性能问题的定位能力。修改订单服务的Feign超时配置因为商品服务被故意延迟了5秒而Feign默认的readTimeout是1秒会导致请求提前超时失败。将超时设为5000ms是为了确保调用链路能够完整走通以便在Zipkin中看到完整的追踪记录。4. Sleuth入门日志中观察链路操作在公共模块common引入spring-cloud-starter-sleuth依赖所有微服务就具备了生成追踪信息的能力。效果调用接口后在每个微服务的控制台日志中你会看到格式类似的输出[应用名, TraceId, SpanId, 是否采样]。分析通过对比不同服务日志中的TraceId你就能手动将一次请求的各个服务环节串联起来。但日志太多时这种方式效率很低所以需要Zipkin。5. Zipkin集成可视化展示Zipkin提供了服务端收集、存储、展示和客户端上报数据的完整方案。Zipkin架构Collector接收客户端上报的追踪数据。Storage存储数据默认内存生产用MySQL或Elasticsearch。API Web UI提供查询界面和RESTful API用于展示调用链。客户端集成在每个需要追踪的微服务中引入spring-cloud-starter-zipkin依赖并配置spring.zipkin.base-url指向Zipkin服务端地址。采样率spring.sleuth.sampler.probability1.0表示100%采样。生产环境建议调低如0.1因为全量采集会产生大量数据影响性能和存储。集成后访问http://localhost:9411就能看到可视化的调用链直观地发现哪个环节耗时最长。6. Zipkin数据持久化生产必备Zipkin默认将数据存在内存中服务重启数据会丢失且无法应对大量数据。生产环境必须持久化。方案一MySQL持久化原理将Span和Annotation信息存储到关系型数据库。特点适合数据量不大、查询简单的场景。但面对海量追踪数据MySQL的读写性能会成为瓶颈。关键点启动Zipkin Server时通过命令行参数指定STORAGE_TYPEmysql和数据库连接信息。方案二Elasticsearch持久化推荐原理将追踪数据存储到Elasticsearch中。特点Elasticsearch专为海量数据搜索和分析设计读写性能高是链路追踪系统最常用的存储方案非常适合大规模生产环境。关键点启动Zipkin Server时通过参数指定STORAGE_TYPEelasticsearch和ES的地址。总结与常见面试点Sleuth的作用在日志中注入TraceId和SpanId将分布式请求链路标记出来。Zipkin的作用收集、存储和展示这些链路数据提供可视化UI。Trace与Span的关系一个Trace包含多个SpanSpan之间有父子关系通过ParentId关联。采样率的重要性生产环境不建议设置100%通常配置为0.1~0.5以减少性能损耗和存储压力。持久化方案选择小规模或演示用MySQL中大规模生产用Elasticsearch。