Micrometer+ZipKin分布式链路追踪

news/2024/7/7 20:40:37 标签: 分布式, springcloud, Micrometer, ZipKin

在这里插入图片描述

目录

背景

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

在大规模分布式与微服务集群下，出现问题时，需要：
1、可实时观察系统整理调用链路情况
2、快速发现并定位问题
3、精准判断故障对系统的影响范围和程度
4、梳理服务之间的依赖关系，并判断依赖关系是否合理是否可优化
5、精准分析调用链的性能瓶颈以及容量规划

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

Micrometer_14">Micrometer

springcloud 对分布式链路追踪提供了支持：Spring Cloud Sleuth 为分布式跟踪提供 Spring Boot 自动配置，但目前Spring Cloud Sleuth 的最后一个次要版本是 3.1，已停止更新，以后使用推荐 Micrometer Tracing
在这里插入图片描述

MicrometerZipKin_17">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_65">ZipKin

Zipkin 是一个分布式跟踪系统。它有助于收集解决服务架构中的延迟问题所需的计时数据。功能包括此数据的收集和查找。
如果日志文件中有跟踪 ID，则可以直接跳转到该 ID。否则，您可以根据服务、操作名称、标签和持续时间等属性进行查询。将为您总结一些有趣的数据，例如在服务中花费的时间百分比，以及操作是否失败。
在这里插入图片描述
Zipkin UI 还显示一个依赖关系图，显示每个应用程序经过的跟踪请求数。这有助于识别聚合行为，包括错误路径或对已弃用服务的调用。
在这里插入图片描述

安装下载

官方支持三种安装下载：Java、Docker 或从源代码运行。
java下载：https://zipkin.io/pages/quickstart
在这里插入图片描述
下载完成后运行jar

java -jar zipkin-server-3.0.0-rc0-exec.jar

在这里插入图片描述
启动完成之后访问http://your_host:9411，成功
在这里插入图片描述

MicrometerZipKin__85">Micrometer+ZipKin 案例演示

Micrometer+ZipKin两者各自分工

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

总父工程pom依赖引入

<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依赖引入

<!--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配置

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

编写接口

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

b服务调用方pom依赖引入

 <!--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配置

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

接口调用

@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}{咱们来日方长，有缘江湖再见，告辞！} 咱们来日方长，有缘江湖再见，告辞！

在这里插入图片描述


http://www.niftyadmin.cn/n/5535240.html

相关文章

如何将等保2.0的要求融入日常安全运维实践中？

如何将等保2.0的要求融入日常安全运维实践中？

等保2.0的基本要求 等保2.0是中国网络安全领域的基本国策和基本制度&#xff0c;它要求网络运营商按照网络安全等级保护制度的要求&#xff0c;履行相关的安全保护义务。等保2.0的实施得到了《中华人民共和国网络安全法》等法律法规的支持&#xff0c;要求相关行业和单位必须按…
阅读更多...
视频网关的作用

视频网关的作用

在数字化时代&#xff0c;视频通信已经成为了人们日常生活和工作中的重要部分。为了满足不同设备和平台之间的视频通信需求&#xff0c;各种视频协议应运而生。然而&#xff0c;这些协议之间的差异使得相互通信变得复杂。因此&#xff0c;视频网关作为一种重要的网络设备&#…
阅读更多...
C++编程逻辑讲解step by step：类之间的交互

C++编程逻辑讲解step by step：类之间的交互

题目 设计一个点类Point&#xff0c;再设计一个矩形类&#xff0c;矩形类使用Point类的两个坐标点作为矩形的对角顶点。并可以输出4个坐标值和面积。 分析 1.点类&#xff0c;自然维护的是一个点的坐标&#xff0c; #include < iostream > using namespace std; class …
阅读更多...
【Rust入门】生成随机数

【Rust入门】生成随机数

文章目录 前言随机数库rand添加rand库到我们的工程生成一个随机数示例代码 总结 前言 在编程中&#xff0c;生成随机数是一种常见的需求&#xff0c;无论是用于数据分析、游戏开发还是模拟实验。Rust提供了强大的库来帮助我们生成随机数。在这篇文章中&#xff0c;我们将通过一…
阅读更多...
[数据集][目标检测]婴儿状态睡觉哭泣检测数据集VOC+YOLO格式7109张3类别

[数据集][目标检测]婴儿状态睡觉哭泣检测数据集VOC+YOLO格式7109张3类别

数据集格式&#xff1a;Pascal VOC格式YOLO格式(不包含分割路径的txt文件&#xff0c;仅仅包含jpg图片以及对应的VOC格式xml文件和yolo格式txt文件) 图片数量(jpg文件个数)&#xff1a;7109 标注数量(xml文件个数)&#xff1a;7109 标注数量(txt文件个数)&#xff1a;7109 标注…
阅读更多...
Qt源码分析：窗体绘制与响应

Qt源码分析：窗体绘制与响应

作为一套开源跨平台的UI代码库&#xff0c;窗体绘制与响应自然是最为基本的功能。在前面的博文中&#xff0c;已就Qt中的元对象系统(反射机制)、事件循环等基础内容进行了分析&#xff0c;并捎带阐述了窗体响应相关的内容。因此&#xff0c;本文着重分析Qt中窗体绘制相关的内容…
阅读更多...
昇思MindSpore学习总结八——静态图加速

昇思MindSpore学习总结八——静态图加速

AI编译框架分为两种运行模式&#xff0c;分别是动态图模式以及静态图模式。MindSpore默认情况下是以动态图模式运行&#xff0c;但也支持手工切换为静态图模式。两种运行模式的详细介绍如下&#xff1a; 1、动态图模式 动态图的特点是计算图的构建和计算同时发生&#xff08;D…
阅读更多...
三维地图Cesium中，如何监听地图点击事件，实现在实体上面鼠标右击时做处理。

三维地图Cesium中，如何监听地图点击事件，实现在实体上面鼠标右击时做处理。

在 Cesium 中&#xff0c;如果你想在实体&#xff08;Entity&#xff09;上实现鼠标右击&#xff08;右键点击&#xff09;的处理&#xff0c;你需要使用 Cesium 的事件系统来监听鼠标事件&#xff0c;并结合一些逻辑来判断点击是否发生在实体上。由于 Cesium 没有直接提供“点…
阅读更多...
最新文章

Copyright @ 2022~2023