一、分布式链路监控与追踪产生背景

在微服务系统中,随着业务的发展,系统会变得越来越大,那么各个服务之间的调用关系也就变得越来越复杂。一个 HTTP 请求会调用多个不同的微服务来处理返回最后的结果,在这个调用过程中,可能会因为某个服务出现网络延迟过高或发送错误导致请求失败,这个时候,对请求调用的监控就显得尤为重要了。Spring Cloud Sleuth 提供了分布式服务链路监控的解决方案

服务与服务之间调用关系
链路指的:一串联多个服务组成一个流程 调用链关系

链路监控 SkyWalkingAgent 链路监控如何溯源_微服务

二、SpringCloud Zipkin 与Sleuth

Zipkin 是一个开放源代码分布式的跟踪系统,由Twitter公司开源,它致力于收集服务的定时数据,以解决微服务架构中的延迟问题,包括数据的收集、存储、查找和展现。
每个服务向zipkin报告计时数据,例如用户每次请求服务的处理时间等,可方便的监测系统中存在的瓶颈。
zipkin会根据调用关系通过Zipkin UI生成依赖关系图。

Spring Cloud Sleuth为服务之间调用提供链路追踪。通过Sleuth可以很清楚的了解到一个服务请求经过了哪些服务,每个服务处理花费了多长。从而让我们可以很方便的理清各微服务间的调用关系。此外Sleuth可以帮助我们:
耗时分析: 通过Sleuth可以很方便的了解到每个采样请求的耗时,从而分析出哪些服务调用比较耗时;
可视化错误: 对于程序未捕捉的异常,可以通过集成Zipkin服务界面上看到;
链路优化: 对于调用比较频繁的服务,可以针对这些服务实施一些优化措施。
Spring Cloud Sleuth可以结合Zipkin,将信息发送到Zipkin,利用Zipkin的存储来存储信息,利用Zipkin Ui来展示数据。

三、搭建Zipkin服务追踪系统

在 Spring Boot 2.0 版本之后,官方已不推荐自己搭建定制了,而是直接提供了编译好的 jar 包。详情可以查看官网:https://zipkin.io/pages/quickstart.html 注意:zipkin官网已经提供定制了,使用官方jar运行即可。

启动方式:
默认端口号启动zipkin服务
java –jar zipkin.jar 默认端口号: 9411
访问地址:http://192.168.18.220:9411

指定端口号启动8080启动zipkin服务
java -jar zipkin.jar --server.port=8080 访问地址:http://192.168.18.220:8080

指定访问rabbitmq 启动
java -jar zipkin.jar --zipkin.collector.rabbitmq.addresses=127.0.0.1

链路监控 SkyWalkingAgent 链路监控如何溯源_jar_02


访问:http://localhost:9411/zipkin/

链路监控 SkyWalkingAgent 链路监控如何溯源_链路_03

四、案例展示

新建三个项目,order调用member,member调用msg
加入统一maven依赖:

<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

application.yml加入zipkin相关配置

###订单服务的端口号
server:
  port: 8001
###服务别名----服务注册到注册中心名称 
spring:
  application:
    name: app-xwhy-order
  zipkin: 
    base-url: http://127.0.0.1:9411/
  ###全部采集  
  sleuth:
    sampler:
      probability: 1.0

eureka:
  client:
    service-url:
    ##### 当前会员服务注册到eureka服务地址
      defaultZone: http://localhost:8100/eureka
    ### 需要将我的服务注册到eureka上
    register-with-eureka: true
    ####需要检索服务
    fetch-registry: true

三个服务分别做相应的配置,使用restTemplate来进行远程调用。

最后可以看到调用关系:

链路监控 SkyWalkingAgent 链路监控如何溯源_链路_04


可以在里面查看详细的调用时间以及接口报错之后的异常提示等等。

五、服务跟踪原理

为了实现请求跟踪,当请求发送到分布式系统的入口端点时, 只需要服务跟踪框架为该请求创建一个唯的跟踪标识, 同时在分布式系统内部流转的时候,框架始终保持传递该唯一标识, 直到返回给请求方为止,这个唯一标识就是前 文中提到的Trace ID。通过Trace ID的记录,我们就能将所有请求过程的日志关联起来。
为了统计各处理单元的时间延迟,当请求到达各个服务组件时,或是处理逻辑到达某个状态时,也通过一个唯一 标识来标记它的开始、 具体过程以及结束,该标识就是前文中提到的Span ID。对于每个Span来说,它必须有开始和结束两个节点,通过记录开始Span和结束Span的时间戳,就能统计出该Span的时间延迟,除了时间戳记录之外,它还可以包含一些其他元数据, 比如事件名称、请求信息等
SpanId记录每一次请求, TraceID记录整个调用链全局ID

  • TraceId 和 SpanId 在微服务中传递追踪
  • TraceId作用是整个微服务调用链过程中保证唯一。
  • SpanId记录每一次请求,耗时时间、接口调用关系。
  • 在微服务中,使用请求头传递TraceId和SpanId,一个TraceId由多个SpanId组合起来。获取到整个微服务调用依赖关系
  • 每次请求生成一个新的spanId