前言:微服务架构上通过业务来划分服务的,通过REST调用,对外暴露的一个接口,可能需要很多个服务协同才能完成这个接口功能,如果链路上任何一个服务出现问题或者网络超时,都会形成导致接口调用失败。随着业务的不断扩张,服务之间互相调用会越来越复杂。为了能够清晰地记录服务的调用链路,方便将来问题的定位,Spring cloud Sleuth组件正是为了解决微服务跟踪而生,产生微服务调用链日志,然后可以结合APM应用性能管理工具进行存储和Web界面展示,比如Skywalking,美团CAT,Pinpoint(当然也有其他的例如Zipkin,Jaeger等产品,不过总体来说不如前面3个完成度高)。
一、Sleuth和Zipkin简介
1.1、Sleuth和Zipkin的联系
Spring Cloud Sleuth主要功能就是在分布式系统中提供链路追踪解决方案。但是Sleuth并没有UI界面,需要集成Zipkin完成数据的收集、存储、查找和展示。
- Sleuth在微服务调用时跟踪产生日志。
- Zipkin是 Twitter 的一个开源项目,基于 Google Dapper实现,是一个链路日志接收服务器,拥有ui可以清晰展示链路调用细节。它主要对处理收集器接收到的跟踪信息,默认会将这些信息存储在内存中,我们也可以修改此存储策略,通过使用其他存储组件将跟踪信息存储到数据库或es中。
Spring Cloud Sleuth 可以结合 Zipkin,将信息发送到 Zipkin,利用 Zipkin 的存储来存储信息,利用 Zipkin UI 来展示数据。
1.2、Sleuth微服务跟踪作用
Sleuth微服务跟踪其实是一个工具,它在整个分布式系统中能跟踪一个用户请求的过程(包括数据采集,数据传输,数据存储,数据分析,数据可视化),捕获这些跟踪数据,就能构建微服务的整个调用链的视图,这是调试和监控微服务的关键工具。
Spring Cloud Sleuth有4个作用:
作用 | 说明 |
提供链路追踪 | 通过sleuth可以很清楚的看出一个请求经过了哪些服务, 可以方便的理清服务间的调用关系 |
性能分析 | 通过sleuth可以很方便的看出每个采集请求的耗时, 分析出哪些服务调用比较耗时,当服务调用的耗时 随着请求量的增大而增大时,也可以对服务的扩容提 供一定的提醒作用 |
数据分析 优化链路 | 对于频繁地调用一个服务,或者并行地调用等, 可以针对业务做一些优化措施 |
可视化 | 对于程序未捕获的异常,可以在zipkpin界面上看到 |
1.3、Sleuth术语
Span:基本工作单元,例如,在一个新建的span中发送一个RPC等同于发送一个回应请求给RPC,span通过一个64位ID唯一标识,trace以另一个64位ID表示,span还有其他数据信息,比如摘要、时间戳事件、关键值注释(tags)、span的ID、以及进度ID(通常是IP地址)
span在不断的启动和停止,同时记录了时间信息,当你创建了一个span,你必须在未来的某个时刻停止它。
Trace:一系列spans组成的一个树状结构,例如,如果你正在跑一个分布式工程,你可能需要创建一个trace。
Annotation:用来及时记录一个事件的存在,一些核心annotations用来定义一个请求的开始和结束
cs - Client Sent -客户端发起一个请求,这个annotion描述了这个span的开始
sr - Server Received -服务端获得请求并准备开始处理它,如果将其sr减去cs时间戳便可得到网络延迟
ss - Server Sent -注解表明请求处理的完成(当请求返回客户端),如果ss减去sr时间戳便可得到服务端需要的处理请求时间
cr - Client Received -表明span的结束,客户端成功接收到服务端的回复,如果cr减去cs时间戳便可得到客户端从服务端获取回复的所有所需时间。
二、Zipkin下载
Zipkin分为两端:服务端和客户端。客户端也就是微服务的应用。客户端需要配置服务端的URL地址,一旦发生服务间的调用时,就会被配置在微服务里面的Sleuth监听器所监听,并生成对应的Trace和Span信息发送给服务端。
2.1 下载Zipkin的jar包(服务端)
下载地址:zipkin-server-2.12.9-exec.jar
2.2 命令行启动Zipkin Server
java -jar zipkin-server-2.12.9-exec.jar
2.3 通过浏览器访问: http://localhost:9411
三、快速集成Sleuth和Zipkin
3.1、pom中引入spring-cloud-starter-zipkin依赖
使用spring-cloud-starter-zipkin,不需要单独引入sleuth和zipkin的依赖。由于每个模块都需要进行链路追踪,所以建议在父工程引入Sleuth依赖。
<!-- 链路跟踪 sleuth和zipkin -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
<version>2.2.0.RELEASE</version>
</dependency>
3.2 yml添加配置(每个微服务都需要进行配置,可以使用配置中心优化))
spring:
sleuth:
web:
client:
# 开启采集链路
enabled: true
sampler:
# 默认采集是 0.1(百分之十),生产环境采用默认,测试环境可以修改为1.0
probability: 1.0
# zipkin服务所在地址
zipkin:
base-url: http://localhost:9411/
3.3、访问微服务,进行测试
http://localhost:8001/order-service/order ,该服务会调用product-service和credit-service
通过网关访问订单微服务的下单接口。在控制台就会有相关的链路信息输出,包括微服务名称、traceId、spanId、是否将链路的追踪结果输出到第三方平台。
3.4、通过Zipkin查看链路信息,发现微服务credit-service的addCredit接口耗时最长,而且标红了(调用超时出错)。
3.5、查看credit-service的addCredit接口接口代码,即可定位问题: