前言
通过记录请求调用的链路信息,可以帮助我们明确调用关系,定位耗时环节,分析用户行为等,现在大多数应用都不会是一个程序,而是有多个服务组成的分布式系统,通过sleuth
可以实现服务间的链路追踪,确定调用关系。以网关为场景,有spring gateway
网关程序提供对外访问,user-rest
程序提供用户相关接口,网关及服务间通过注册中心进行注册发现,当用户请求网关时,网关会调用相应下层服务,获取结果返给用户,下层服务可能还会调用其它服务,这一过程就是一个调用链,以此为例实现sleuth
与zipkin
集成,得益于spring
的高度集成,集成过程也非常简单。
集成sleuth
在各层服务程序中加入sleuth
支持,添加maven
依赖:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
添加配置:
spring:
sleuth:
sampler:
probability: 1 # 样本采集比率
其中抽样率控制传输到远程服务的比例,如设为0.5
,则对每一请求会有50%
的机率收集跟踪信息并传输至远程存储服务(如zipkin
)。
此时启动程序,调用相应接口,程序有日志打印,就会看到sleuth
已经将跟踪信息注入到了日志中,如下:
INFO [user-rest,2ffbf34c7ab86715,0d14ed6c18834a3c] 880 --- [io-18100-exec-1] t.w.userrest.controller.UserController : Get user info ...
其中INFO
后中括号内内容即为sleuth
注入的跟踪信息,有逗号隔开三部分组成,第一部分为服务名,第二部分为parent trace id
,第三部分为span id
,对于一条完整的调用链,其trace id
应该是一致的,对于调用链中的每一服务,其span id
是一致的,也就是通过trace id
可唯一确定一条完整调用链,span id
可确定调用链中的一个环节。调用链及服务调用依赖关系即可根据这两个id
分析生成。
引入zipkin
只引入sleuth
追踪信息只是在服务自身的log
日志中可见,通过引入zipkin
,统一收集各服务的调用链信息并分析,可直观的看到各分布式服务的调用链、依赖关系及耗时情况。
下载zipkin
服务
zipkin
提供了自动下载脚本,脚本会自动下载zipkin
的jar
包并进行md5
校验:
curl -sSL https://zipkin.io/quickstart.sh | bash -s
下载下来的为一个jar
包,直接通过java -jar
运行即可:
java -jar zipkin.jar
访问http://localhost:9411/zipkin/
即可看到zipkin
界面。
集成zipkin
在各服务中引入依赖:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
<version>2.2.8.RELEASE</version>
</dependency>
配置文件中配置zipkin
的服务地址:
spring:
zipkin:
base-url: http://127.0.0.1:9411
sleuth
检测到zipkin
依赖后,会自动将链路信息报告给zipkin
,zipkin
将信息上报给server
端。
启动程序进行访问,在zipkin
中即可看到依赖关系:
其还比较贴心的动态展示了数据流的方向。
同时可查询到调用链:
点击记录,可查看到详细的调用链信息,如下:
同时点击相应记录能看到具体每个span
的时间信息:
并且标签中可以看到调用的方法:
除了这种以http
的方式上报信息至server
端外,zipkin
还提供了mysql
、Elasticsearch
、RabbitMq
等的集成,可以应用于需求更复杂的链路信息存储、分析场景。