发现问题前端
在微服务框架中,一个由客户端发起的请求在后端系统中会通过多个不一样的服务节点调用来协同产生最后的请求结果,每个前端请求都会造成一条复杂的分布式服务调用链路,链路中的任何一环出现高延时或错误都会引发整个请求最后的失败。因此在较复杂的系统中,一个调用链路中会有不少个微服务,无疑咱们须要对链路上的微服务进行跟踪。java
解决方案spring
SpringCloud Sleuth就提供了一套完整的服务跟踪的解决方案,在分布式系统中提供了追踪解决方案而且兼容支持了zipkin,SpringCloud Sleuth负责对微服务调用链路的收集整理,而zipkin负责对链路的展示。shell
SpringCloud从F版以后就不须要本身构建Zipkin Server了,只须要调用相关jar包便可后端
zipkin的jar包下载地址:https://dl.bintray.com/openzipkin/maven/io/zipkin/java/zipkin-server/框架
我下的是当前最新的zipkin-server-2.12.9-exec.jar。进入到该jar包的目录,在命令行中输入java -jar命令运行该jar文件maven
java -jar zipkin-server-2.12.9-exec.jar
访问 http://localhost:9411/zipkin/ 进入zipkin监控平台页面分布式
名词解释:微服务
Trace
:相似于树结构的Span结合,表示一条调用链路,存在惟一标识学习
span
:标识调用链路来源,通俗理解span就是一次请求信息
完整的调用链路
一条链路经过Trace Id惟一标识,Span标识发起的请求信息,各span经过parent id关联起来。
整个链路的依赖关系以下
在须要被链路监控的微服务中引入以下依赖:
<!--包含了sleuth+zipkin--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency>
好比在咱们最开始学习Eureka服务注册中心时使用的8001微服务(服务提供方)和80微服务(服务消费方),那时候80微服务做为服务消费方访问8001提供的微服务,咱们如今在这两个微服务中引入上述依赖,并在配置文件中配置zipkin和sleuth的配置信息:
spring: zipkin: base-url: http://localhost:9411 sleuth: sampler: # 采样率值介于0到1之间,1表示所有采集 probability: 1
在80和8001微服务都引入了上述依赖并添加了上面的配置后,启动Eureka服务注册中心、8001服务提供方服务、80服务消费方服务,而后咱们用80调用8001的服务进行测试,在zipkin面板中便可查看服务调用链路。