在微服务框架中,一个由客户端发起的请求在后端系统中会通过多个不一样的服务节点调用来协同产生最后的请求结果,每个前端请求都会造成一条复杂的分布式服务调用链路,链路中的任何一环出现高延时或错误都会引发整个请求最后的失败。java
Spring Cloud Sleuth为Spring Cloud实现了一种分布式跟踪解决方案。git
完整的调用链路:一条链路经过Trace Id惟一标识,Span标识发起的请求信息,各span经过parent id关联起来。spring
下载地址:https://dl.bintray.com/openzipkin/maven/io/zipkin/java/zipkin-server/shell
运行zipkin:后端
$ java -jar zipkin-server-2.12.9-exec.jar
访问:localhost:9411/zipkin/
app
本次链路追踪的演示,选择不新建项目,选取老项目演示。框架
选取cloud-provider-payment8001
做为服务的提供者,选取cloud-consumer-order80
做为服务的消费者。maven
俩服务都添加配置pom.xml分布式
<!--包含了sleuth+zipkin--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency>
俩服务都添加配置yml
spring: application: name: cloud-payment-service # 服务名称! zipkin: base-url: http://localhost:9411 # 监控中心 sleuth: sampler: #采样率值介于 0 到 1 之间,1 则表示所有采集 probability: 1
服务提供者提供测试接口
@GetMapping("/payment/zipkin") public String paymentZipkin(){ return "payment zipkin !"; }
服务消费者提供测试接口
@GetMapping("/consumer/payment/zipkin") public String paymentZipkin(){ return restTemplate.getForObject("http://localhost:8001" + "/payment/zipkin/",String.class); }
依次启动7001,80,8001模块,消费者调用测试接口,产生调用链路,进入zipkin管理页面,能够观测调用链路的响应状况等。
本系列文章为《尚硅谷SpringCloud教程》的学习笔记【版本稍微有些不一样,后续遇到bug再作相关说明】,主要作一个长期的记录,为之后学习的同窗提供示例,代码同步更新到Gitee:https://gitee.com/tqbx/spring-cloud-learning,而且以标签的形式详细区分每一个步骤,这个系列文章也会同步更新。