概述
前边讲了限流,到底这些参数设多少比较合适?要设这些参数,首先需要知道各个服务之间的依赖关系,其次需要知道服务之间调用的流量大小。如何观测这些参数呢?就需要用到调用链监控。
调用链不仅能解决上述问题,还能够对一个业务请求进行全链路的追踪,以及各个环节上的耗时情况,方便于故障排查、服务扩容。下边来看看调用链监控。
基本原理
参考, 调用链监控最早有Google Dapper论文而来,Twitter提供了开源的实现zipkin。
先来看看一些基本属于:
再来看看结构图:

对于一次调用,只生成一个trance Id,然后各个节点(span)记录发生的事件,将这些事件统一汇总到一个服务上进行统一的聚合,生成整个调用链的监控。
使用
zipkin由客户端与服务器组成,服务器提供了自己的UI,便于可视化观察数据。Spring Cloud Sleuth是对Zipkin的一个封装,对于Span、Trace等信息的生成、接入HTTP Request,以及向Zipkin Server发送采集信息等全部自动完成。
zipkin可以支持服务之间多种通信方式,可以是REST也可以是消息队列。这里主要看看对REST的监控。
启动zipkin服务
docker pull openzipkin/zipkin
docker run --name zipkin -d -p 9411:9411 openzipkin/ziplin
zipkin服务中的数据可以持久化,默认情况下是在内存中,重启会丢失。
依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
配置
spring.zipkin.base-url=http://localhost:9411/
spring.zipkin.sender.type=web | rabbit | kafka
spring.sleuth.sampler.probability=1.0
spring.zipkin.discovery-client-enabled = false
spring.zipkin.compression.enabled = false
配置服务的url、采样比例(默认0.1)、通信的方式。
使用
调用链监控对代码没有侵入,使用上可以从9411端口查看zipkin服务的web页面。
在实现上,源码基本上是在 spring-cloud-sleuth-core中,在其cloud.sleuth.instrument.web中,可以看到具体对web增强的源码。方式上与resilience4j很像,通过AOP或者拦截器,实现功能的增强。
在客户端方面,TraceRestTemplateCustomizer
实现对RestTemplate的注入。通过RestTemplateInterceptorInjector将TracingClientHttpRequestInterceptor注入到RestTemplate的interceptors中。具体的实现逻辑是在TracingClientHttpRequestInterceptor中实现的。
在服务器方面,通过TraceWebAspect对Controller等进行了增强。