目录

spirngcloud请求链路追踪

Spring Cloud Sleuth 官网

概述

服务链路追踪

微服务架构是一个分布式架构,它按业务划分服务单元,一个分布式系统往往有很多个服务单元。由于服务单元数量众多,业务的复杂性,如果出现了错误和异常,很难去定位。主要体现在,一个请求可能需要调用很多个服务,而内部服务的调用复杂性,决定了问题难以定位。所以微服务架构中,必须实现分布式链路追踪,去跟进一个请求到底有哪些服务参与,参与的顺序又是怎样的,从而达到每个请求的步骤清晰可见,出了问题,很快定位。

http://img.cana.space/picStore/20201113164300.png

举几个例子:

1、在微服务系统中,一个来自用户的请求,请求先达到前端A(如前端界面),然后通过远程调用,达到系统的中间件B、C(如负载均衡、网关等),最后达到后端服务D、E,后端经过一系列的业务逻辑计算最后将数据返回给用户。对于这样一个请求,经历了这么多个服务,怎么样将它的请求过程的数据记录下来呢?这就需要用到服务链路追踪。

2、分析微服务系统在大压力下的可用性和性能。

Zipkin可以结合压力测试工具一起使用,分析系统在大压力下的可用性和性能。

设想这么一种情况,如果你的微服务数量逐渐增大,服务间的依赖关系越来越复杂,怎么分析它们之间的调用关系及相互的影响?

spring boot对zipkin的自动配置可以使得所有RequestMapping匹配到的endpoints得到监控,以及强化了RestTemplate,对其加了一层拦截器,使得由它发起的http请求也同样被监控。

Google开源的 Dapper链路追踪组件,并在2010年发表了论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》,这篇文章是业内实现链路追踪的标杆和理论基础,具有非常大的参考价值。

目前,链路追踪组件有Google的Dapper,Twitter 的Zipkin,以及阿里的Eagleeye (鹰眼)等,它们都是非常优秀的链路追踪开源组件。

本文主要讲述如何在Spring Cloud Sleuth中集成Zipkin。在Spring Cloud Sleuth中集成Zipkin非常的简单,只需要引入相应的依赖和做相关的配置即可。

简介

一条链路通过Trace Id唯一标识,Span标识发起的请求信息,各Span通过parent id关联起来

http://img.cana.space/picStore/20201113165548.png

简化之后:

http://img.cana.space/picStore/20201113170637.png

可以看到就是一个有向图,Trace类似于树结构的Span集合,标识一条调用链路;Span标识调用链路来源,通俗地理解Span就是一次请求信息。

sleuth与Zipkin关系

spring cloud提供了spring-cloud-sleuth-zipkin来方便集成zipkin实现(指的是Zipkin Client,而不是Zipkin服务器),该jar包可以通过spring-cloud-starter-zipkin依赖来引入。

Zipkin

Zipkin官网

Zipkin是什么

Zipkin分布式跟踪系统;它可以帮助收集时间数据,解决在microservice架构下的延迟问题;它管理这些数据的收集和查找;Zipkin的设计是基于谷歌的Google Dapper论文。 每个应用程序向Zipkin报告定时数据,Zipkin UI呈现了一个依赖图表来展示多少跟踪请求经过了每个应用程序;如果想解决延迟问题,可以过滤或者排序所有的跟踪请求,并且可以查看每个跟踪请求占总跟踪时间的百分比。

Zipkin原理

针对服务化应用全链路追踪的问题,Google发表了Dapper论文,介绍了他们如何进行服务追踪分析。其基本思路是在服务调用的请求和响应中加入ID,标明上下游请求的关系。利用这些信息,可以可视化地分析服务调用链路和服务间的依赖关系。

对应Dpper的开源实现是Zipkin,支持多种语言包括JavaScript,Python,Java, Scala, Ruby, C#, Go等。其中Java由多种不同的库来支持

Spring Cloud Sleuth是对Zipkin的一个封装,对于Span、Trace等信息的生成、接入HTTP Request,以及向Zipkin Server发送采集信息等全部自动完成。Spring Cloud Sleuth的概念图见上图。

Zipkin架构

跟踪器(Tracer)位于你的应用程序中,并记录发生的操作的时间和元数据,提供了相应的类库,对用户的使用来说是透明的,收集的跟踪数据称为Span;将数据发送到Zipkin的仪器化应用程序中的组件称为Reporter,Reporter通过几种传输方式之一将追踪数据发送到Zipkin收集器(collector),然后将跟踪数据进行存储(storage),由API查询存储以向UI提供数据。 架构图如下:

http://img.cana.space/picStore/20201113165739.png

Zipkin下载和启动

下载

有三种安装方法:

Zipkin的使用比较简单,官网有说明几种方式: 1、容器 Docker Zipkin项目能够建立docker镜像,提供脚本和docker-compose.yml来启动预构建的图像。最快的开始是直接运行最新镜像:

1
docker run -d -p 9411:9411 openzipkin/zipkin

2、下载jar 如果你有java 8或更高版本,上手最快的方法是把新版本作为一个独立的可执行jar,Zipkin使用springboot来构建的:

1
2
curl -sSL https://zipkin.io/quickstart.sh | bash -s
java -jar zipkin.jar

3、下载源代码运行 Zipkin可以从源运行,如果你正在开发新的功能。要实现这一点,需要获取Zipkin的源代码并构建它。

本次我们使用第二种方式安装启动,成功启动后访问 http://127.0.0.1:9411/zipkin/

http://img.cana.space/picStore/20201113172757.png

演示链路追踪

这里使用现有的工程:

  • cloud-consumerzk-order80 服务调用方
  • cloud-provider-payment8004 服务提供者
  • cloud-eureka-single-server7000 注册中心
  1. 启动zk服务器

  2. 服务提供者和服务消费者(调用方)改造相同,如下:

    pom依赖

    1
    2
    3
    4
    
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-starter-zipkin</artifactId>
            </dependency>
    

    yml配置

    1
    2
    3
    4
    5
    6
    7
    8
    9
    
    spring:
      zipkin:
       # zipkin服务端的地址
        base-url: http://localhost:9411
      sleuth:
        sampler:
         # percentage是采样比例,设置为1.0时代表全部强求都需要采样。Sleuth默认采样算法的实现是Reservoir sampling,
         # 具体的实现类是PercentageBasedSampler,默认的采样比例为: 0.1(即10%)。
          percentage: 1.0
    
  3. 验证

    访问:http://localhost/order/paymentZK

    查看zipkin界面,如下:

    http://img.cana.space/picStore/20201113183828.png

    查看服务之间的依赖关系

    http://img.cana.space/picStore/20201113183853.png