boot接入zipkin

zipkin接入

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

1 zipkin简介

1.1 作用

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

1.2 原理

zipkin架构图如下所示:
boot接入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等进行的请求。

boot接入zipkin

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

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

1.3 使用场景

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

2 zipkin服务器

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

开发接入无需关心。

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

boot接入zipkin

3 项目接入zipkin

3.1 maven依赖

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

3.2 配置文件

application.yml 加入下面配置

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

4 注意点

4.1 RestTemplate 销毁导致无法形成调用链

 @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。

如下图:

boot接入zipkin

服务之间依赖如下图:

boot接入zipkin

 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。

如下图:

boot接入zipkin

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

服务之间依赖如下图:

boot接入zipkin

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

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

4.2 采集率以调用链首个服务为主

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

上一篇:分布式服务追踪与调用链 Zikpin


下一篇:java版b2b2c社交电商spring cloud分布式微服务(九)服务链路追踪(Spring Cloud Sleuth)