随着业务发展,系统拆分导致系统调用链路愈发复杂一个前端请求可能最终需要调用很多次后端服务才能完成,当整个请求陷入性能瓶颈或不可用时,我们是无法得知该请求是由某个或某些后端服务引起的,这时就需要解决如何快读定位服务故障点,以对症下药。于是就有了分布式系统调用跟踪的诞生。
Spring Cloud Sleuth 也为我们提供了一套完整的解决方案。在本文中,我们将详细介绍如何使用 Spring Cloud Sleuth + Zipkin 来为我们的微服务架构增加分布式服务跟踪的能力。
Spring Cloud Sleuth implements a distributed tracing solution for Spring Cloud, borrowing heavily from Dapper, Zipkin and HTrace. For most users Sleuth should be invisible, and all your interactions with external systems should be instrumented automatically. You can capture data simply in logs, or by sending it to a remote collector service.
Spring Cloud Sleuth是Spring Cloud实施分布式跟踪解决方案,大量借用Dapper,Zipkin和HTrace。 对于大多数用户来说,侦探应该是隐形的,并且所有与外部系统的交互都应该自动进行检测。 您可以简单地在日志中捕获数据,也可以将数据发送到远程收集器服务。
SpringCloudSleuth 借用了 Dapper 的术语:
Spring Cloud Sleuth 为服务之间调用提供链路追踪。通过 Sleuth 可以很清楚的了解到一个服务请求经过了哪些服务,每个服务处理花费了多长。从而让我们可以很方便的理清各微服务间的调用关系。此外 Sleuth 可以帮助我们:
Spring Cloud Sleuth 可以结合 Zipkin,将信息发送到 Zipkin,利用 Zipkin 的存储来存储信息,利用 Zipkin UI 来展示数据。
这是 Spring Cloud Sleuth 的概念图:
只需要在pom.xml的 dependencies 中添加如下依赖,就可以为应用整合sleuth:
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-sleuth</artifactId> </dependency>
整合完成之后,启动项目,调用一个请求(我人为的关闭了应用要调用的另一个微服务,导致了请求失败),这是看控制台日志:
2019-10-29 16:28:57.417 INFO [study01,,,] 5830 --- [-192.168.31.101] o.s.web.servlet.DispatcherServlet : Completed initialization in 27 ms 2019-10-29 16:28:57.430 INFO [study01,,,] 5830 --- [-192.168.31.101] com.zaxxer.hikari.HikariDataSource : HikariPool-1 - Starting... 2019-10-29 16:28:57.433 INFO [study01,,,] 5830 --- [-192.168.31.101] com.zaxxer.hikari.HikariDataSource : HikariPool-1 - Start completed. 2019-10-29 16:28:58.520 DEBUG [study01,42d9bd786504f775,42d9bd786504f775,false] 5530 --- [nio-8881-exec-1] c.e.s.feignClient.CommentFeignClient : [CommentFeignClient#find] ---> GET http://study02/find HTTP/1.1 2019-10-29 16:28:58.520 DEBUG [study01,42d9bd786504f775,42d9bd786504f775,false] 5530 --- [nio-8881-exec-1] c.e.s.feignClient.CommentFeignClient : [CommentFeignClient#find] ---> END HTTP (0-byte body) 2019-10-29 16:28:58.520 DEBUG [study01,42d9bd786504f775,42d9bd786504f775,false] 5530 --- [nio-8881-exec-1] c.s.i.w.c.f.TraceLoadBalancerFeignClient : Before send 2019-10-29 16:28:58.646 INFO [study01,42d9bd786504f775,42d9bd786504f775,false] 5530 --- [nio-8881-exec-1] c.netflix.config.ChainedDynamicProperty : Flipping property: study02.ribbon.ActiveConnectionsLimit to use NEXT property: niws.loadbalancer.availabilityFilteringRule.activeConnectionsLimit = 2147483647 2019-10-29 16:28:58.661 INFO [study01,42d9bd786504f775,42d9bd786504f775,false] 5530 --- [nio-8881-exec-1] c.netflix.loadbalancer.BaseLoadBalancer : Client: study02 instantiated a LoadBalancer: DynamicServerListLoadBalancer:{NFLoadBalancer:name=study02,current list of Servers=[],Load balancer stats=Zone stats: {},Server stats: []}ServerList:null 2019-10-29 16:28:58.667 INFO [study01,42d9bd786504f775,42d9bd786504f775,false] 5530 --- [nio-8881-exec-1] c.n.l.DynamicServerListLoadBalancer : Using serverListUpdater PollingServerListUpdater 2019-10-29 16:28:58.683 INFO [study01,42d9bd786504f775,42d9bd786504f775,false] 5530 --- [nio-8881-exec-1] c.n.l.DynamicServerListLoadBalancer : DynamicServerListLoadBalancer for client study02 initialized: DynamicServerListLoadBalancer:{NFLoadBalancer:name=study02,current list of Servers=[],Load balancer stats=Zone stats: {},Server stats: []}ServerList:com.alibaba.cloud.nacos.ribbon.NacosServerList@591b62cf 2019-10-29 16:28:58.707 DEBUG [study01,42d9bd786504f775,42d9bd786504f775,false] 5530 --- [nio-8881-exec-1] o.s.c.s.i.a.ContextRefreshedListener : Context successfully refreshed 2019-10-29 16:28:58.755 DEBUG [study01,42d9bd786504f775,42d9bd786504f775,false] 5530 --- [nio-8881-exec-1] c.s.i.w.c.f.TraceLoadBalancerFeignClient : Exception thrown
可以看见日志的形式和之前不太一样了,首先启动日志里面多了个中括号: [study01,,,] ;而当应用请求报异常的时候,中括号中有了这些数据: [study01,42d9bd786504f775,42d9bd786504f775,false]
study01是应用名称,42d9bd786504f775是 trace ID,42d9bd786504f775是span ID,false表示是不是要把这条数据上传给zipkin。这时,就可以通过日志分析应用哪里出了问题、哪个阶段出了问题。
PS:可以在应用中添加如下配置:
logging: level: org.springframework.cloud.sleuth: debug
这段配置的用处是让sleuth打印更多的日志,从而进一步帮助我们分析错误【我上面粘出的日志就是添加配置之后的结果】。
Zipkin 是 Twitter 的开源分布式跟踪系统,它基于 Google Dapper 实现,它致力于收集服务的时序数据,以解决微服务架构中的延迟问题,包括数据的收集、存储、查找和展现。
curl -sSL https://zipkin.io/quickstart.sh | bash -s
访问如下地址下载:
https://search.maven.org/remote_content?g=io.zipkin.java&a=zipkin-server&v=LATEST&c=exec
下载完成之后,在下载的jar所在目录,执行 java -jar *****.jar
命令即可启动Zipkin Server
访问http://localhost:9411 即可看到Zipkin Server的首页。
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency>
PS:当使用了 spring-cloud-starter-zipkin 之后,前面添加 spring-cloud-starter-sleuth 就不需要了,因为前者包含了后者。
spring: zipkin: base-url: http://localhost:9411/ sleuth: sampler: # 抽样率,默认是0.1(90%的数据会被丢弃) # 这边为了测试方便,将其设置为1.0,即所有的数据都会上报给zipkin probability: 1.0
启动项目,产生请求之后,打开zipkin控制台,可以刚刚请求的信息(按耗时降序排列):
点击可以查看请求的详情:
这张图中, Server Start 表示的是 Server Received ; Server Finish 表示的是 Server Sent 。
因为客户端发生在浏览器上,而浏览器并没有整合zipkin,所以zipkin中没有 Client Sent 和 Client Received 数据。
前面搭建Zipkin是基于内存的,如果Zipkin发生重启的话,数据就会丢失,这种方式是不适用于生产的,所以我们需要实现数据持久化。
Zipkin给出三种数据持久化方法:
相关的官方文档:https://github.com/openzipkin/zipkin#storage-component , 本文将介绍 Elasticsearch实现Zipkin数据持久化
我们需要下载什么版本的Elasticsearch呢,官方文档给出了建议,5-7版本都可以使用(本文使用的是Elasticsearch6.8.2,因为Elasticsearch7开始后需要jdk11支持):
The Elasticsearch component uses Elasticsearch 5+ features, but is tested against Elasticsearch 6-7.x.
下载完成后,解压缩软件包,进入bin目录,执行 ./elasticsearch
即可启动Elasticsearch:
访问 http://localhost:9200/
,出现如下页面,说明Elasticsearch启动成功:
zipkin提供了很多的环境变量,配置环境变量就可以将数据存储进Elasticsearch。
更多环境变量参照:https://github.com/openzipkin/zipkin/tree/master/zipkin-server#environment-variables
执行下面代码重新启动zipkin:
STORAGE_TYPE=elasticsearch ES_HOSTS=localhost:9200 java -jar zipkin-server-2.12.9-exec.jar
产生请求之后,访问http://localhost:9411/zipkin/,可以看见刚刚请求的数据:
停调zipkin,然后再次启动,访问http://localhost:9411/zipkin/,可以看见数据依然存在:
说明此时,数据已经实现了持久化。
从官方文档可以看出,使用Elasticsearch进行zipkin数据持久化之后,Zipkin的依赖关系分析功能无法使用了。
Note: This store requires a spark job to aggregate dependency links.
我们需要整合 zipkin-dependencies 来实现依赖关系图功能。 zipkin-dependencies 是zipkin的一个子项目,启动非常的简单。
下载:
curl -sSL https://zipkin.io/quickstart.sh | bash -s io.zipkin.dependencies:zipkin-dependencies:LATEST zipkin-dependencies.jar
启动:
STORAGE_TYPE=elasticsearch ES_HOSTS=localhost:9200 java -jar zipkin-dependencies.jar
这边只需要把项目启动,就可以展示依赖关系图了,这里就不再演示了。
注意:zipkin-dependencies启动之后会自动停止,所以建议使用定时任务让操作系统定时启动zipkin-dependencies。
分析昨天的数据(OS/X下的命令)
STORAGE_TYPE=elasticsearch java -jar zipkin-dependencies.jar 'date -uv-ld + %F'
分析昨天的数据(Linux下的命令)
STORAGE_TYPE=elasticsearch java -jar zipkin-dependencies.jar 'date -u -d '1 day ago' + %F'
分析指定日期的数据
STORAGE_TYPE=elasticsearch java -jar zipkin-dependencies.jar 2019-10-29