boot接入zipkin | 易学教程

Zipkin是一种分布式跟踪系统。它有助于收集解决微服务架构中的延迟问题所需的时序数据。它管理这些数据的收集和查找。Zipkin的设计基于 Google Dapper论文，对原理感兴趣可以看下。

简单说就是采集各服务之间互相调用的信息：谁调用了谁，调用是否发生故障，调用耗时多少。并提供可视化界面。方便快速定位服务故障点。

zipkin架构图如下所示：

Trace

Zipkin使用Trace结构表示对一次请求的跟踪，一次请求可能由后台的若干服务负责处理，每个服务的处理是一个Span，Span之间有依赖关系，Trace就是树结构的Span集合；

Span

每个服务的处理跟踪是一个Span，可以理解为一个基本的工作单元，包含了一些描述信息：id，parentId，name，timestamp，duration，annotations等

Components

有4个组件组成Zipkin：collector，storage，search，web UI
collector：一旦跟踪数据到达Zipkin collector守护进程，它将被验证，存储和索引，以供Zipkin收集器查找；
storage：Zipkin最初数据存储在Cassandra上，因为Cassandra是可扩展的，具有灵活的模式，并在Twitter中大量使用；但是这个组件可插入，除了Cassandra之外，还支持ElasticSearch和MySQL；
search：一旦数据被存储和索引，我们需要一种方法来提取它。查询守护进程提供了一个简单的JSON API来查找和检索跟踪，主要给Web UI使用；
web UI：创建了一个GUI，为查看痕迹提供了一个很好的界面；Web UI提供了一种基于服务，时间和注释查看跟踪的方法。

通过mq技术（如Apache Kafka或RabbitMQ）（或任何其他Spring Cloud Stream binder）进行的请求。
在Spring MVC controller收到的HTTP header。
通过Netflix Zuul传过来的microroxy请求。
使用RestTemplate等进行的请求。

埋点实现：主要通过filter，aop等拦截技术，获取到Span信息，通过Transport（有三个主要的传输方式：Http、kafka和Scribe）异步发送给zipkin服务器。

zipkin支持mysql、cassandra、elasticsearch几种存储方案。mysql性能可能有点问题，建议后期改es做持久化。

随着业务越来越复杂，服务也随之拆分。一个前端的请求可能需要多次的服务调用最后才能完成。为了获取服务之间相互依赖信息，以及各服务之间的调用情况。方便快速定位服务故障点，接入zipkin。

项目地址：http://gitlab.uniubi.com/huanghuizhou/uniubi-microservice-medusa-zipkin-hhz.git

开发接入无需关心。

启动后访问 http://192.168.1.172:9411

        <!--zipkin链路追踪-->         <dependency>             <groupId>org.springframework.cloud</groupId>             <artifactId>spring-cloud-starter-zipkin</artifactId>             <version>2.1.1.RELEASE</version>         </dependency>

application.yml 加入下面配置

spring:   zipkin:     base-url: http://192.168.1.172:9411   sleuth:     sampler:         #采集比例 默认0.1 只采集10%       probability: 0.1

 @Bean public RestTemplate getRestTemplate(){     return new RestTemplate(); }  @Autowired private RestTemplate restTemplate; public void test(){     ResponseEntity<Object> response = restTemplate.exchange("http://localhost:9500/message/smsLoad?pageSize=10&pageNum=1", HttpMethod.GET, null, Object.class); }

通过bean 注入restTemplate时能正常形成调用链。span深度为2。

如下图：

服务之间依赖如下图：

 public void test1(){         RestTemplate restTemplate=new RestTemplate();         ResponseEntity<Object> response = restTemplate.exchange("http://localhost:9500/message/smsLoad?pageSize=10&pageNum=1", HttpMethod.GET, null, Object.class);         System.out.println(111);     }

通过局部变量RestTemplate 进行调用，无法形成调用链。span深度为1。

如下图：

形成两个单独的调用记录。

服务之间依赖如下图：

个人猜想：A通过局部变量RestTemplate调用B时。调用B之前A先埋点发送信息到zipkin此时Trance_id：A_ID，由于RestTemplate是局部变量，调用完直接销毁。当访问B进行埋点时，由于RestTemplate已销毁获取不到之前Trance_id，生成了一个新的Trance_id：B_ID。因此无法形成调用链。

spring cloud feign客户端以bean的形式存在，无需担心此问题。

例：A采集率10%，B采集率100%。 A调用B形成一个调用链。只有10%概率会被采集到zipkin服务器上。
反之亦凡。

标签

Zipkin

resttemplate