服务跟踪原理
分布式系统的服务跟踪主要包括下面两个关键点:
1.为了实现请求跟踪,当请求发送到分布式系统的入口端点时,只需要服务跟踪框架为该请求创建一个唯一的跟踪标识Trace ID,
同时在分布式系统内部流转的时候,框架失踪保持该唯一标识,直到返回给请求方位置。
服务追踪的追踪单元是从客户发起请求(request)抵达被追踪系统的边界开始,到被追踪系统向客户返回响应(response)为止的过程,称为一个“trace”。
2.为了统计各处理单元的时间延迟,当请求到达各个服务组件时,也是通过一个唯一标识Span ID来标记它的开始,具体过程以及结束。对每一个Span来说,它必须有开始和结束两个节点,通过记录开始Span和结束Span的时间戳,就能统计出该Span的时间延迟,除了时间戳记录之外,它还可以包含一些其他元数据,比如时间名称、请求信息等。
这样,若干个有序的 span 就组成了一个 trace。在系统向外界提供服务的过程中,会不断地有请求和响应发生,也就会不断生成 trace,把这些带有span 的 trace 记录下来,就可以描绘出一幅系统的服务拓扑图。附带上 span 中的响应时间,以及请求成功与否等信息,就可以在发生问题的时候,找到异常的服务;根据历史数据,还可以从系统整体层面分析出哪里性能差,定位性能优化的目标。
Sleuth
Spring Cloud Sleuth 为服务之间的调用提供链路追踪。通过Sleuth可以很清楚的了解到一个服务请求经过了哪些服务,每个服务处理花费多久。此外还可以进行:
- 耗时分析:分析哪些服务调用比较耗时;
- 可视化错误:对于程序未捕捉的异常,可以通过集成Zipkin服务界面上看到;
- 链路优化:对于调用比较频繁的服务,可以针对这些服务实施一些优化措施。
spring cloud sleuth可以结合zipkin,将信息发送到zipkin,利用zipkin的存储来存储信息,利用zipkin ui 来展示数据。
ZipKin
Zipkin是一个开放源代码分布式 的跟踪系统,由Twitter公司开源,它致力于收集服务的定时数据,以解决微服务架构中的延迟问题,包括数据的收集、存储、查找和展现。
服务端搭建
可以通过运行可执行jar包快速搭建zipkin服务器,也可以自行搭建。
SpringBoot 2.0 版本之后,官方已不推荐自己搭建定制,而是直接提供了编译好的 jar包。
2.0之后,springboot没有为zipkin等相关依赖指定版本号,版本兼容问题十分明显。
zipkin server 搭建
java -jar zipkin-server-2.12.9-exec.jar
访问zipkin的管理界面
localhost:9411
客户端搭建
这里以order80 为例
文件结构
Controller
添加
@GetMapping("/consumer/payment/zipkin")
public String paymentZipkin(){
String result = restTemplate.getForObject("http://localhost:8001"+"/payment/zipkin/",String.class);
return result;
}
yml
需要添加的核心配置
spring:
application:
name: cloud-order-service
zipkin:
#监控数据去哪儿看
base-url: http://localhost:9411
sleuth:
sampler:
#采样值介于0到1之间,1则表示全部采集
probability: 1
pom
添加依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
依次启动
测试
多次发起请求
zipkin中查看