1. 简介
微服务架构上通过业务来划分服务的,通过REST调用,对外暴露的一个接口,可能需要很多个服务协同才能完成这个接口功能,如果链路上任何一个服务出现问题或者网络超时,都会形成导致接口调用失败。随着业务的不断扩张,服务之间互相调用会越来越复杂。
我们知道微服务架构就是按照功能模块把我们的应用抽取成一个一个独立的服务,而服务和服务之间相互调用,相互影响,一个服务可能会去调用很多个其他的服务,由于服务数量众多 ,业务复杂性比较高,如果出现异常或错误,我们很难快速精确的去定位到问题服务,所以在微服务的架构中,必须实现分布式链路追踪,去追踪出每一个服务每一个请求到底有哪些服务的参与,请求路线到底是如何执行的,从而让我们服务之间的调用关系清晰可见,出现问题也能够快速进行定位。本章主要讲述在Spring Cloud Sleuth中集成Zipkin ,常见的链路追踪组件有:阿里的Eagleeye等,Twitter的Zipkin等
2. Sleuth配置
2.1 pom.xml
添加依赖,要在服务的调用方和服务的提供方都添加此依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
2.2 参数指标
运行程序,调用接口发现控制台打印了一些如下信息
[order-service,96f95a0dd81fe3ab,852ef4cfcdecabf3,false]
1、第一个值,spring.application.name的值
2、第二个值,96f95a0dd81fe3ab ,sleuth生成的一个ID,叫Trace ID,用来标识一条请求链路,一条请求链路中包含一个Trace ID,多个Span ID
3、第三个值,852ef4cfcdecabf3、spanid 基本的工作单元,获取元数据,如发送一个http
4、第四个值:false,是否要将该信息输出到zipkin服务中来收集和展示。
3. Zipkin配置(可视化链路追踪系统)
zipkin是大规模分布式系统的APM工具(Application Performance Management),基于Google Dapper的基础实现,和sleuth结合可以提供可视化web界面分析调用链路耗时情况
我们使用docker 启动Zipkin,docker的使用教程可以看博主以前的博客
docker run -d -p 9411:9411 openzipkin/zipkin
浏览器访问
3.1 zinkip配置
spring:
# zinkip 服务所在地址
zipkin:
base-url: "http://192.168.1.103:9411/"
# 配置采样百分比, 默认是0.1f 是百分之10 1代表全部采样
sleuth:
sampler:
probability: 1