Micrometer+ZipKin分布式链路追踪

目录

背景

一个系统页面上的按钮点击到结果反馈,在微服务框架里,是由N个服务组成返回结果,中间可能经过a->b->c->b->a,或a->b->a->c等等简单或复杂重复的服务调用,如果调用链路某一节点出错导致服务崩溃,将无法快速定位问题解决。

在大规模分布式与微服务集群下,出现问题时,需要:

1、可实时观察系统整理调用链路情况

2、快速发现并定位问题

3、精准判断故障对系统的影响范围和程度

4、梳理服务之间的依赖关系,并判断依赖关系是否合理是否可优化

5、精准分析调用链的性能瓶颈以及容量规划

以上分布式链路追踪技术可以解决的问题,分布式链路追踪(Distributed Tracing),就是将一次分布式请求还原成调用链路,进行日志记录,性能监控并将一次分布式请求的调用情况集中展示。比如各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态等等。

Micrometer

springcloud 对分布式链路追踪提供了支持:Spring Cloud Sleuth 为分布式跟踪提供 Spring Boot 自动配置,但目前Spring Cloud Sleuth 的最后一个次要版本是 3.1,已停止更新,以后使用推荐 Micrometer Tracing

Micrometer与ZipKin之间的关系

可能会有同志们在想,既然有了Micrometer作为链路追踪,那么还要ZipKin干嘛?

看以上图,可理解为,Micrometer作为链路追踪可以采集到整条完整链路的所有请求信息,但是以数据方式呈现在日志当中,虽然也可以直接观看,但想要更客观统计和分析,仍然有局限性。ZipKin支持接入Micrometer的数据,作为仪表板,可以清晰看见每条链路的请求响应数据。

专业术语

Span :基本工作单位。例如,发送 RPC 是一个新的跨度,向 RPC 发送响应也是如此。跨度还包含其他数据,例如描述、时间戳事件、键值注释(标记)、导致这些值的跨度的 ID 以及进程 ID(通常为 IP 地址)
Trace :形成树状结构的一组跨度。例如,如果运行分布式大数据存储,则 PUT 跟踪可能由请求形成。
Annotation/Event :用于及时记录事件的存在。
Tracer :处理跨度生命周期的库。它可以通过报告器/导出器创建、启动、停止和报告跨度到外部系统。
Tracing context :要使分布式跟踪正常工作,跟踪上下文(跟踪标识符、跨度标识符等)必须通过进程(例如通过线程)和网络传播。
Log correlation :跟踪上下文的某些部分(例如跟踪标识符、跨度标识符)可以填充到给定应用程序的日志中。然后,可以将所有日志收集到单个存储中,并通过跟踪 ID 对它们进行分组。这样,就可以从按时间顺序排列的所有服务中获取单个业务操作(跟踪)的所有日志。
Latency analysis tools:收集导出的跨度并可视化整个跟踪的工具。允许轻松分析延迟。

分布式链路追踪原理

见上图,分布式链路追踪是怎么知道服务的上游和下游是谁呢?

那么一条链路追踪会在每个服务调用的时候加上Trace ID(全局唯一id) 和 Span ID(每次请求的id)

链路通过TraceId唯一标识,

Span标识发起的请求信息,各span通过parent id 关联起来 (Span:表示调用链路来源,通俗的理解span就是一次请求信息)

简单来说

第一个节点:Span ID = A,Parent ID = null,Service 1 接收到请求。

第二个节点:Span ID = B,Parent ID= A,Service 1 发送请求到 Service 2 返回响应给Service 1 的过程。

第三个节点:Span ID = C,Parent ID= B,Service 2 的 中间解决过程。

第四个节点:Span ID = D,Parent ID= C,Service 2 发送请求到 Service 3 返回响应给Service 2 的过程。

第五个节点:Span ID = E,Parent ID= D,Service 3 的中间解决过程。

第六个节点:Span ID = F,Parent ID= C,Service 3 发送请求到 Service 4 返回响应给 Service 3 的过程。

第七个节点:Span ID = G,Parent ID= F,Service 4 的中间解决过程。

通过 Parent ID 就可找到父节点,整个链路即可以进行跟踪追溯了。

ZipKin

Zipkin 是一个分布式跟踪系统。它有助于收集解决服务架构中的延迟问题所需的计时数据。功能包括此数据的收集和查找。

如果日志文件中有跟踪 ID,则可以直接跳转到该 ID。否则,您可以根据服务、操作名称、标签和持续时间等属性进行查询。将为您总结一些有趣的数据,例如在服务中花费的时间百分比,以及操作是否失败。

Zipkin UI 还显示一个依赖关系图,显示每个应用程序经过的跟踪请求数。这有助于识别聚合行为,包括错误路径或对已弃用服务的调用。

安装下载

官方支持三种安装下载:Java、Docker 或从源代码运行。

java下载:https://zipkin.io/pages/quickstart

下载完成后运行jar

powershell 复制代码
java -jar zipkin-server-3.0.0-rc0-exec.jar

启动完成之后访问http://your_host:9411,成功

Micrometer+ZipKin 案例演示

Micrometer+ZipKin两者各自分工

  • Micrometer:数据采集
  • ZipKin:图形展示

本案例采用两个服务模块演示,a服务提供者、b服务调用者

总父工程pom依赖引入

xml 复制代码
<properties>
        <micrometer-tracing.version>1.2.0</micrometer-tracing.version>
        <micrometer-observation.version>1.12.0</micrometer-observation.version>
        <feign-micrometer.version>12.5</feign-micrometer.version>
        <zipkin-reporter-brave.version>2.17.0</zipkin-reporter-brave.version>
</properties>
        
<!--micrometer-tracing-bom导入链路追踪版本中心  1-->
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-tracing-bom</artifactId>
    <version>${micrometer-tracing.version}</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>
<!--micrometer-tracing指标追踪  2-->
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-tracing</artifactId>
    <version>${micrometer-tracing.version}</version>
</dependency>
<!--micrometer-tracing-bridge-brave适配zipkin的桥接包 3-->
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-tracing-bridge-brave</artifactId>
    <version>${micrometer-tracing.version}</version>
</dependency>
<!--micrometer-observation 4-->
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-observation</artifactId>
    <version>${micrometer-observation.version}</version>
</dependency>
<!--feign-micrometer 5-->
<dependency>
    <groupId>io.github.openfeign</groupId>
    <artifactId>feign-micrometer</artifactId>
    <version>${feign-micrometer.version}</version>
</dependency>
<!--zipkin-reporter-brave 6-->
<dependency>
    <groupId>io.zipkin.reporter2</groupId>
    <artifactId>zipkin-reporter-brave</artifactId>
    <version>${zipkin-reporter-brave.version}</version>
</dependency>

引入包的作用是什么呢?

由于Micrometer Tracing是一个门面工具自身并没有实现完整的链路追踪系统,具体的链路追踪另外需要引入的是第三方链路追踪系统的依赖:

micrometer-tracing-bom:导入链路追踪版本中心,体系化说明

micrometer-tracing:指标追踪

micrometer-tracing-bridge-brave:一个Micrometer模块,用于与分布式跟踪工具 Brave 集成,以收集应用程序的分布式跟踪数据。Brave是一个开源的分布式跟踪工具,它可以帮助用户在分布式系统中跟踪请求的流转,它使用一种称为"跟踪上下文"的机制,将请求的跟踪信息存储在请求的头部,然后将请求传递给下一个服务。在整个请求链中,Brave会将每个服务处理请求的时间和其他信息存储到跟踪数据中,以便用户可以了解整个请求的路径和性能。

micrometer-observation

一个基于度量库 Micrometer的观测模块,用于收集应用程序的度量数据。

feign-micrometer:一个Feign HTTP客户端的Micrometer模块,用于收集客户端请求的度量数据。

zipkin-reporter-brave:一个用于将 Brave 跟踪数据报告到Zipkin 跟踪系统的库。

补充包:spring-boot-starter-actuator SpringBoot框架的一个模块用于监视和管理应用程序(服务的健康检查)

a服务提供方pom依赖引入

xml 复制代码
<!--micrometer-tracing指标追踪  1-->
        <dependency>
            <groupId>io.micrometer</groupId>
            <artifactId>micrometer-tracing</artifactId>
        </dependency>
        <!--micrometer-tracing-bridge-brave适配zipkin的桥接包 2-->
        <dependency>
            <groupId>io.micrometer</groupId>
            <artifactId>micrometer-tracing-bridge-brave</artifactId>
        </dependency>
        <!--micrometer-observation 3-->
        <dependency>
            <groupId>io.micrometer</groupId>
            <artifactId>micrometer-observation</artifactId>
        </dependency>
        <!--feign-micrometer 4-->
        <dependency>
            <groupId>io.github.openfeign</groupId>
            <artifactId>feign-micrometer</artifactId>
        </dependency>
        <!--zipkin-reporter-brave 5-->
        <dependency>
            <groupId>io.zipkin.reporter2</groupId>
            <artifactId>zipkin-reporter-brave</artifactId>
        </dependency>

yml配置

yaml 复制代码
# ========================zipkin===================
management:
  zipkin:
    tracing:
      endpoint: http://localhost:9411/api/v2/spans
  tracing:
    sampling:
      probability: 1.0 #采样率默认为0.1(0.1就是10次只能有一次被记录下来),值越大收集越及时。

编写接口

java 复制代码
/**
     * Micrometer(Sleuth)进行链路监控的例子
     * @param id
     * @return
     */
    @GetMapping(value = "/pay/micrometer/{id}")
    public String myMicrometer(@PathVariable("id") Integer id);

b服务调用方pom依赖引入

xml 复制代码
 <!--micrometer-tracing指标追踪  1-->
    <dependency>
        <groupId>io.micrometer</groupId>
        <artifactId>micrometer-tracing</artifactId>
    </dependency>
    <!--micrometer-tracing-bridge-brave适配zipkin的桥接包 2-->
    <dependency>
        <groupId>io.micrometer</groupId>
        <artifactId>micrometer-tracing-bridge-brave</artifactId>
    </dependency>
    <!--micrometer-observation 3-->
    <dependency>
        <groupId>io.micrometer</groupId>
        <artifactId>micrometer-observation</artifactId>
    </dependency>
    <!--feign-micrometer 4-->
    <dependency>
        <groupId>io.github.openfeign</groupId>
        <artifactId>feign-micrometer</artifactId>
    </dependency>
    <!--zipkin-reporter-brave 5-->
    <dependency>
        <groupId>io.zipkin.reporter2</groupId>
        <artifactId>zipkin-reporter-brave</artifactId>
    </dependency>

a、b服务之间的pom引入是一样的 不需要吧zipkin的依赖引入,因为总父工程的pom里面已经有了,子服务不需要引入。

yml配置

yaml 复制代码
# zipkin图形展现地址和采样率设置
management:
  zipkin:
    tracing:
      endpoint: http://localhost:9411/api/v2/spans
  tracing:
    sampling:
      probability: 1.0 #采样率默认为0.1(0.1就是10次只能有一次被记录下来),值越大收集越及时。

接口调用

java 复制代码
@RestController
@Slf4j
public class OrderMicrometerController
{
    @Resource
    private PayFeignApi payFeignApi;

    @GetMapping(value = "/feign/micrometer/{id}")
    public String myMicrometer(@PathVariable("id") Integer id)
    {
        return payFeignApi.myMicrometer(id);
    }
}

服务启动后,调用接口http://localhost/feign/micrometer/1

打开网址http://your_host:9411,看到对应界面

可清楚看到链路的每个服务节点的详细信息,包括断路器等都可检测到。

相关文献

micrometer官网:https://docs.micrometer.io/micrometer/reference/overview.html

zipkin官网:https://zipkin.io/

当然除了Micrometer还有其他技术可以做链路追踪,具体情况参考自家公司的服务架构、项目流量决定,Skywalking作为链路追踪也是不错的

就先说到这 \color{#008B8B}{ 就先说到这} 就先说到这
在下 A p o l l o \color{#008B8B}{在下Apollo} 在下Apollo
一个爱分享 J a v a 、生活的小人物, \color{#008B8B}{一个爱分享Java、生活的小人物,} 一个爱分享Java、生活的小人物,
咱们来日方长,有缘江湖再见,告辞! \color{#008B8B}{咱们来日方长,有缘江湖再见,告辞!} 咱们来日方长,有缘江湖再见,告辞!

相关推荐
Data跳动4 小时前
Spark内存都消耗在哪里了?
大数据·分布式·spark
Java程序之猿5 小时前
微服务分布式(一、项目初始化)
分布式·微服务·架构
来一杯龙舌兰6 小时前
【RabbitMQ】RabbitMQ保证消息不丢失的N种策略的思想总结
分布式·rabbitmq·ruby·持久化·ack·消息确认
节点。csn8 小时前
Hadoop yarn安装
大数据·hadoop·分布式
NiNg_1_2349 小时前
基于Hadoop的数据清洗
大数据·hadoop·分布式
隔着天花板看星星10 小时前
Spark-Streaming集成Kafka
大数据·分布式·中间件·spark·kafka
技术路上的苦行僧14 小时前
分布式专题(8)之MongoDB存储原理&多文档事务详解
数据库·分布式·mongodb
龙哥·三年风水15 小时前
workman服务端开发模式-应用开发-后端api推送修改二
分布式·gateway·php
小小工匠15 小时前
分布式协同 - 分布式事务_2PC & 3PC解决方案
分布式·分布式事务·2pc·3pc
闯闯的日常分享17 小时前
分布式锁的原理分析
分布式