大家先看几个问题,对于一个大型的微服务架构系统,会有哪些常见问题?
如何串联调用链,快速定位问题
如何厘清微服务之间的依赖关系
如何进行各个服务接口的性能分折
如何跟踪业务流的处理顺序
Sleuth介绍及应用
spring Cloud Sleuth为 spring Cloud提供了分布式跟踪的解决方案,它大量借用了
Google Dapper、 Twitter Zipkin和 Apache HTrace的设计
先来了解一下 Sleuth的术语, Sleuth借用了 Dapper的术语。
span(跨度):基本工作单元。 span用一个64位的id唯一标识。除ID外,
span还包含其他数据,例如描述、时间戳事件、键值对的注解(标签), spanID、
span父 ID等。 span被启动和停止时,记录了时间信息。初始化 span被称
为”rootspan”,该 span的 id和 trace的 ID相等。
trace(跟踪):一组共享”rootspan”的 span组成的树状结构称为 traceo trace
也用一个64位的 ID唯一标识, trace中的所有 span都共享该 trace的 IDO
annotation(标注): annotation用来记录事件的存在,其中,核心
annotation用来定义请求的开始和结束。
a) CS(
Client sent客户端发送):客户端发起一个请求,该 annotation描述了
span的开
始。
b) SR(
server Received服务器端接收):服务器端获得请求并准备处理它。如
果用 SR减去 CS时间戳,就能得到网络延迟。
c) SS(
server sent服务器端发送):该 annotation表明完成请求处理(当响应
发回客户端时)。如果用 SS减去 SR时间戳,就能得到服务器端处理请求所需的时间。
d) CR(
Client Received客户端接收): span结束的标识。客户端成功接收到服
务器端的响应。如果 CR减去 CS时间戳,就能得到从客户端发送请求到服务器响应的所需
的时间。
下图详细描述了请求依次经过Service1—Service2—Service3—Service4时,span、
trace、annotation的变化
Sleuth整合Zipkin实现分布式链路跟踪
整合sleuth
见示例:11-ms-simple-provider-user-trace
添加依赖
启动项目,访问地址:http://localhost:8000/1,查看后台日志,发现有trace和span的日
志打印
Zipkin简介
Zipkin是 Twitter开源的分布式跟踪系统,基于 Dapper的论文设计而来。它的主要功能是
收集系统的时序数据,从而追踪微服务架构的系统延时等问题。 Zipkin还提供了一个非常
友好的界面,来帮助分析追踪数据。官网地址:http://zipkin.io
编写Zipkin Server见示例:11-ms-trace-zipkin-server
添加依赖,并在启动类上添加注解@EnableZipkinServer,声明一个Zipkin Server
启动项目,访问地址:http://localhost:9411/zipkin/,效果如下图
简单讲解下图中各个查询条件的含义:
第一列表示Service Name,也就是各个微服务spring.application.name的值。第二列表
示Span的名称,all表示所有。Start time和End time,分别用于指定起始时间和截止时
间。Duration表示持续时间,即Span从创建到关闭所经历的时间。Limit表示查询几条数
据。类似于 MySQL数据库中的 limit关键词。Annotations Query,用于自定义查询条
件。
微服务整合Zipkin
用户微服务整合Zipkin
见示例:11-ms-simple-provider-user-trace-zipkin
添加主要依赖
在配置文件中新增如下内容
spring.zipkin.base-url:指定Zipkin的地址。
spring.sleuth.sampler.percentage:指定需采样的请求的百分比,默认值是0.1,即
10%。这是因为在分布式系统中,数据量可能会非常大,因此采样非常重要。但是我们示
例数据少最好配置为1全采样
订单微服务整合Zipkin类似,见示例:11-ms-simple-consumer-order-trace-zipkin
启动这两个项目,再启动Zipkin服务,访问订单微服务:http://localhost:8010/user/1,
然后再次查看Zipkin服务:http://localhost:9411/zipkin/,能查询到微服务调用的跟踪日
志