谷粒商城-高级-80 -高并发监控-Sleuth 与 Zipkin 服务链路追踪

一、Sleuth概念

为什么需要Spring Cloud Sleuth

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

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

Google开源的 Dapper链路追踪组件,并在2010年发表了论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》,这篇文章是业内实现链路追踪的标杆和理论基础,具有非常大的参考价值。
目前,链路追踪组件有Google的Dapper,Twitter 的Zipkin,以及阿里的Eagleeye (鹰眼)等,它们都是非常优秀的链路追踪开源组件。

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

Spring Cloud Sleuth官方文档:
https://docs.spring.io/spring-cloud-sleuth/docs/current-SNAPSHOT/reference/html/

说明:Sleuth 是 Spring Cloud 开源的组件,而不属于 Spring Cloud Alibaba,之前还以为是阿里开源的组件。

基本术语

Spring Cloud Sleuth采用的是Google的开源项目Dapper的专业术语。

  • Span:基本工作单元,发送一个远程调度任务 就会产生一个Span,Span是一个64位ID唯一标识的,Trace是用另一个64位ID唯一标识的,Span还有其他数据信息,比如摘要、时间戳事件、Span的ID、以及进度ID。

  • Trace:一系列Span组成的一个树状结构。请求一个微服务系统的API接口,这个API接口,需要调用多个微服务,调用每个微服务都会产生一个新的Span,所有由这个请求产生的Span组成了这个Trace。

  • Annotation:用来及时记录一个事件的,一些核心注解用来定义一个请求的开始和结束 。这些注解包括以下:

    • cs - Client Sent -客户端发送一个请求,这个注解描述了这个Span的开始
    • sr - Server Received -服务端获得请求并准备开始处理它,如果将其sr减去cs时间戳便可得到网络传输的时间。
    • ss - Server Sent (服务端发送响应)–该注解表明请求处理的完成(当请求返回客户端),如果ss的时间戳减去sr时间戳,就可以得到服务器请求的时间。
    • cr - Client Received (客户端接收响应)-此时Span的结束,如果cr的时间戳减去cs时间戳便可以得到整个请求所消耗的时间。

二、整合Sleuth

1、服务提供者与消费者导入依赖
由于链路追踪服务在所有微服务中都要用,所以,直接导入到gulimall-common通用服务。
gulimall-common/pom.xml

 <!-- spring cloud sleuth 链路追踪 -->
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-sleuth</artifactId>
    </dependency>

2、打开debug日志
gulimall-order/src/main/resources/application.yml

# 开启debug日志(上线关掉)
logging:
  level:
    org.springframework.cloud.openfeign: debug
    org.springframework.cloud.sleuth: debug

三、整合zipkin可视化观察

通过Sleuth 产生的调用链监控信息,可以得知微服务之间的调用链路,但监控信息只输出到控制台不方便查看。我们需要一个图形化的工具-zipkin。Zipkin是 Twitter 开源的分布式跟踪系统,主要用来收集系统的时序数据,从而追踪系统的调用问题。zipkin官网地址如下:https://zipkin.io/

file

1、docker安装zipkin服务器

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

查看是否安装成功:

[vagrant@localhost ~]$ sudo docker ps

CONTAINER ID        IMAGE                 COMMAND                  CREATED             STATUS                                 PORTS                                                                                                                                       NAMES
a2a2cafc7d8b        openzipkin/zipkin     "/bin/sh -c /zipkin/…"   2 minutes ago       Up About a minute (health: starting)   9410/tcp, 0.0.0.0:9411->9411/tcp                                                                                                            stupefied_albattani

可以看到zipkin已经安装成功。

2、导入依赖
在通用模块导入zipkin依赖:
gulimall-common/pom.xml

    <!-- spring cloud sleuth 链路追踪 -->
<!--    <dependency>-->
<!--      <groupId>org.springframework.cloud</groupId>-->
<!--      <artifactId>spring-cloud-starter-sleuth</artifactId>-->
<!--    </dependency>-->

    <!-- zipkin依赖也同时包含了 sleuth,可以省略上边sleuth 的依赖引用 -->
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-zipkin</artifactId>
    </dependency>

zipkin依赖也同时包含了 sleuth,可以省略 sleuth 的依赖引用。

3、添加zipkin相关配置
gulimall-order/src/main/resources/application.yml

spring:
  datasource:
    username: root
    password: root
    url: jdbc:mysql://192.168.10.10:3306/gulimall_oms
    driver-class-name: com.mysql.cj.jdbc.Driver
  #  配置nacos注册中心
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
    # sentinel控制台地址配置
    sentinel:
      transport:
        port: 8719
        dashboard: localhost:8333
  application:
    name: gulimall-order
  #zipkin配置
  zipkin:
    base-url: http://192.168.10.10:9411/ # zipkin服务器地址
    # 关闭服务发现,否则spring cloud会把zipkin的url当做服务名称
    discoveryClientEnabled: false
    sender:
      type: web #设置使用http的方式传输数据,也可以使用RabbitMQ,Kafka
  sleuth:
    sampler:
      probability: 1 # 设置抽样采集率为100%,默认为0.1,即10%

  thymeleaf:
    cache: false   # 测试期间关掉缓存
  redis:
    host: 192.168.10.10
    prot: 6379
  session:
    store-type: redis  # Session store type,SpringSession整合,使用redis作为session存储
mybatis-plus:
  mapper-location: classpath:/mapper/**/*.xml
  global-config:
    db-config:
      id-type: auto  # id主键自增
server:
  port: 9000
  servlet:
    session:
      timeout: 30m  # Session timeout,SpringSession整合
# 开启debug日志(上线关掉)
logging:
  level:
    org.springframework.cloud.openfeign: debug
    org.springframework.cloud.sleuth: debug

然后将我们其他微服务也加入zipkin的配置。

4、发送远程请求测试
发送登录请求:http://auth.gulimall.com/login.html ,可以看到已经追踪到了登录动作:

file

5、控制台打印

2020-09-18 10:24:50.623 DEBUG [gulimall-product,c25bf52b7a3974ae,40c9f872de58f128,true] 44733 --- [io-10001-exec-1] c.a.g.product.dao.SpuInfoDao.selectById  : <==      Total: 1
2020-09-18 10:24:50.626 DEBUG [gulimall-product,c25bf52b7a3974ae,40c9f872de58f128,true] 44733 --- [io-10001-exec-1] c.a.g.product.dao.BrandDao.selectById    : ==>  Preparing: SELECT brand_id,name,logo,show_status,sort,descript,first_letter FROM pms_brand WHERE brand_id=? 
2020-09-18 10:24:50.627 DEBUG [gulimall-product,c25bf52b7a3974ae,40c9f872de58f128,true] 44733 --- [io-10001-exec-1] c.a.g.product.dao.BrandDao.selectById    : ==> Parameters: 4(Long)

四、zipkin数据持久化

默认zipkin是保存在内存中,我们也可以保存在MySQL或Elasticsearch中,因为日志数据比较庞大,所以推荐保存在Elasticsearch中。

通过 docker的方式

docker run --env STORAGE_TYPE=elasticsearch --env ES_HOSTS=192.168.10.10:9200 openzipkin/zipkin-dependencies

五、复杂测试

给购物车添加商品,并且下单,我们可以看看这个链路跟踪的信息。

file

可以看到这个链路追踪非常强大,RabbitMQ的也可以捕捉到。

file

点进去第一个追踪,可以看到在提交订单时有一个请求超时了,颜色是红色,提交订单所有涉及的服务都被捕捉到了,在后期排查问题的时候非常方便。

也可以看到微服务的依赖图:
file

总之一句话,Zipkin非常强大,以后在面对服务卡的时候就很容易找到执行慢的问题了,到底是网络的问题还是我们代码写的不够好,使用Zipkin就可以一目了然。


相关文章:
Spring Cloud Sleuth官方文档
zipkin官方文档
为什么需要Spring Cloud Sleuth

为者常成,行者常至