大家好，欢迎来到IT知识分享网。

服务链路追踪

为什么需要服务追踪

在微服务架构下，由于进行了服务拆分，一次请求往往需要涉及多个服务，
每个服务可能是由不同的团队开发，使用了不同的编程语言，还有可能部署在不同的机器上，分布在不同的数据中心。
服务跟踪系统

可以跟踪记录一次用户请求都发起了哪些调用，
经过哪些服务处理，并且记录每一次调用所涉及的服务的详细信息
通过查看完整的调用链路，形成拓补图可以更加直观的了解业务，
也可以针对当前的系统进行分析，是否需要扩容、优化接口、失败缓解

通过日志快速定位是调用失败的环节。

Sleuth概述

简介

Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案
并且兼容支持了 zipkin，你只需要在pom文件中引入相应的依赖即可

服务追踪说明

微服务架构是通过业务来划分服务的 使用 REST 调用。
对外暴露的一个接口，可能需要很多个服务协同才能完成这个接口功能
如果链路上任何一个服务出现问题或者网络超时 都会形成导致接口调用失败。
随着业务的不断扩张，服务之间互相调用会越来越复杂。

在这里插入图片描述

随着服务的越来越多，对调用链的分析会越来越复杂。它们之间的调用关系也许如下：

在这里插入图片描述
好壮观的：冠状病毒呀！！

Sleuth链路追踪入门

虽然，理论比较难弄, 但代码实现到不是很困难！

链路追踪, 主要是因为：
微服务架构，不同模块完成不同的事情…
一个功能由多个模块构成… 模块之间相互依赖… 而为了更方便的浏览业务. 以及防止因某个模块出错：快速的定位错误排错完善…
出现的技术！
所以一般来说：每个模块都要进行链路追踪配置！

依赖：

因为，每个模块都要进行 链路追踪！ 就直接定义在父工程模块下了！

pom.xml

<!-- 引入Sleuth依赖 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

.yml 配置文件

每个模块都要哦~
application.yml添加日志级别为了能够在控制台中看到每次调用的情况！方便实时进行分析、

.yml

#yml 配置不在任何属性节点下！
logging:
  level:
    root: INFO              
    org.springframework.web.servlet.DispatcherServlet: DEBUG		# DispatcherServlet 日志级别！ 
    org.springframework.cloud.sleuth: DEBUG     					# sleuth 日志级别

启动微服务，调用之后，我们可以在控制台观察到sleuth的日志输出。

网关：

调用者：
在这里插入图片描述

提供者：
在这里插入图片描述

其中 9bd993c22c807eda是TraceId，后面的是 Span
仔细分析每个微服务的日志，不难看出请求的具体过程。
查看日志文件并不是一个很好的方法 可以使用Zipkin 进行可视化的查看服务之间的链路请求！
当微服务越来越多日志文件也会越来越多，通过Zipkin可以将日志聚合，并进行可视化展示和全文检索。

Zipkin的概述

Zipkin 是 Twitter 的一个开源项目

基于 Google Dapper 论文实现,
它致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。
我们可以使用它来收集各个服务器上请求链路的跟踪数据:
并通过它提供的 REST API 接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序
从而及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源。
除了面向开发的 API 接口之外，它也提供了方便的 UI 组件来帮助我们直观的搜索跟踪信息和分析请求链路明细
Zipkin 提供了可插拔数据存储方式：In-Memory、MySql、Cassandra 以及 Elasticsearch。

Zipkin 的基础架构，它主要由 4 个核心组件构成：

在这里插入图片描述

Collector：收集器组件
它主要用于处理从外部系统发送过来的跟踪信息，
将这些信息转换为 Zipkin内部处理的 Span 格式，以支持后续的存储、分析、展示等功能
Storage: 存储组件
它主要对处理收集器接收到的跟踪信息，
默认会将这些信息存储在内存中，
我们也可以修改此存储策略，通过使用其他存储组件 将跟踪信息存储到数据库中。
RESTful API: API 组件
它主要用来提供外部访问接口。
比如给客户端展示跟踪信息，或是外接系统访问以实现监控等。
Web UI
基于 API 组件实现的上层应用。通过 UI 组件用户可以方便而有直观地查询和分析跟踪信息。

Zipkin Server的部署和配置

Zipkin Server下载

从spring boot 2.0开始，官方就不再支持使用自建Zipkin Server的方式进行服务链路追踪
*而是直接提供了编译好的 jar 包来给我们使用。可以从官方网站下载先下载Zipkin的web UI *

我们这里下载的是 zipkin-server-2.12.9-exec.jar

启动

windows 控制台：java -jar zipkin-server-2.12.9-exec.jar 启动 Zipkin Server
在这里插入图片描述

默认Zipkin Server的请求端口为 `9411`

在这里插入图片描述

客户端Zipkin + Sleuth整合

通过查看日志分析微服务的调用链路并不是一个很直观的方案

结合zipkin可以很直观地显示微服务之间的调用关系。

因为Sleuth是在所以模块下进行链路追踪的， 所以模块下都要进行配置哦！*

客户端添加依赖

同样父工程下添加：pom.xml

<!-- 客户端Zipkin+Sleuth整合 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

客户端配置文件

Spring 属性节点下配置！
yml.xml

spring:
  application:
    name: order-provider
  zipkin:
    base-url:  http://127.0.0.1:9411/ 	#zipkin server的请求地址
    sender:
      type: web 						#请求方式,默认以http的方式向zk server发送追踪数据
  sleuth:
    sampler:
      probability: 1.0 #采样的百分比,所有的监控记录...

指定了zipkin server的地址
下面制定需采样的百分比，默认为0.1，即10%，这里配置1，是记录全部的sleuth信息

测试：

启动Zipkin Service。通过浏览器发送一次微服务请求。 我们可以根据条件追踪每次请求调用过程
在这里插入图片描述

链路追踪Sleuth-Zipkin与Mysql数据的持久化:

上面说了：
在这里插入图片描述
存在内存中: Zipkin服务关闭，监控的数据就丢失了！

Zipkin持久化数据库！ `Mysql`

在这里插入图片描述
mysql 脚本：

`information_schema`/* SQLyog Ultimate v11.33 (64 bit) MySQL - 5.5.58 : Database - zipkin ********************************************************************* */`zipkin_dependencies`


/*!40101 SET NAMES utf8 */;

/*!40101 SET SQL_MODE=''*/;

/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
CREATE DATABASE /*!32312 IF NOT EXISTS*/`zipkin` /*!40100 DEFAULT CHARACTER SET utf8 */;

USE `zipkin`;

/*Table structure for table `zipkin_annotations` */

DROP TABLE IF EXISTS `zipkin_annotations`;

CREATE TABLE `zipkin_annotations` (
  `trace_id_high` bigint(20) NOT NULL DEFAULT '0' COMMENT 'If non zero, this means the trace uses 128 bit traceIds instead of 64 bit',
  `trace_id` bigint(20) NOT NULL COMMENT 'coincides with zipkin_spans.trace_id',
  `span_id` bigint(20) NOT NULL COMMENT 'coincides with zipkin_spans.id',
  `a_key` varchar(255) NOT NULL COMMENT 'BinaryAnnotation.key or Annotation.value if type == -1',
  `a_value` blob COMMENT 'BinaryAnnotation.value(), which must be smaller than 64KB',
  `a_type` int(11) NOT NULL COMMENT 'BinaryAnnotation.type() or -1 if Annotation',
  `a_timestamp` bigint(20) DEFAULT NULL COMMENT 'Used to implement TTL; Annotation.timestamp or zipkin_spans.timestamp',
  `endpoint_ipv4` int(11) DEFAULT NULL COMMENT 'Null when Binary/Annotation.endpoint is null',
  `endpoint_ipv6` binary(16) DEFAULT NULL COMMENT 'Null when Binary/Annotation.endpoint is null, or no IPv6 address',
  `endpoint_port` smallint(6) DEFAULT NULL COMMENT 'Null when Binary/Annotation.endpoint is null',
  `endpoint_service_name` varchar(255) DEFAULT NULL COMMENT 'Null when Binary/Annotation.endpoint is null',
  UNIQUE KEY `trace_id_high` (`trace_id_high`,`trace_id`,`span_id`,`a_key`,`a_timestamp`) COMMENT 'Ignore insert on duplicate',
  KEY `trace_id_high_2` (`trace_id_high`,`trace_id`,`span_id`) COMMENT 'for joining with zipkin_spans',
  KEY `trace_id_high_3` (`trace_id_high`,`trace_id`) COMMENT 'for getTraces/ByIds',
  KEY `endpoint_service_name` (`endpoint_service_name`) COMMENT 'for getTraces and getServiceNames',
  KEY `a_type` (`a_type`) COMMENT 'for getTraces',
  KEY `a_key` (`a_key`) COMMENT 'for getTraces',
  KEY `trace_id` (`trace_id`,`span_id`,`a_key`) COMMENT 'for dependencies job'
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED;

/*Data for the table `zipkin_annotations` */

/*Table structure for table `zipkin_dependencies` */

DROP TABLE IF EXISTS `zipkin_dependencies`;

CREATE TABLE `zipkin_dependencies` (
  `day` date NOT NULL,
  `parent` varchar(255) NOT NULL,
  `child` varchar(255) NOT NULL,
  `call_count` bigint(20) DEFAULT NULL,
  UNIQUE KEY `day` (`day`,`parent`,`child`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED;

/*Data for the table `zipkin_dependencies` */

/*Table structure for table `zipkin_spans` */

DROP TABLE IF EXISTS `zipkin_spans`;

CREATE TABLE `zipkin_spans` (
  `trace_id_high` bigint(20) NOT NULL DEFAULT '0' COMMENT 'If non zero, this means the trace uses 128 bit traceIds instead of 64 bit',
  `trace_id` bigint(20) NOT NULL,
  `id` bigint(20) NOT NULL,
  `name` varchar(255) NOT NULL,
  `parent_id` bigint(20) DEFAULT NULL,
  `debug` bit(1) DEFAULT NULL,
  `start_ts` bigint(20) DEFAULT NULL COMMENT 'Span.timestamp(): epoch micros used for endTs query and to implement TTL',
  `duration` bigint(20) DEFAULT NULL COMMENT 'Span.duration(): micros used for minDuration and maxDuration query',
  UNIQUE KEY `trace_id_high` (`trace_id_high`,`trace_id`,`id`) COMMENT 'ignore insert on duplicate',
  KEY `trace_id_high_2` (`trace_id_high`,`trace_id`,`id`) COMMENT 'for joining with zipkin_annotations',
  KEY `trace_id_high_3` (`trace_id_high`,`trace_id`) COMMENT 'for getTracesByIds',
  KEY `name` (`name`) COMMENT 'for getTraces and getSpanNames',
  KEY `start_ts` (`start_ts`) COMMENT 'for getTraces ordering and range'
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED;

/*Data for the table `zipkin_spans` */

/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

启动Zipkin Server (附带数据库)

如果，以及启动了上面的，要记得关闭哦！

Windows 启动命令：

java -jar zipkin-server-2.12.9-exec.jar --STORAGE_TYPE=mysql --MYSQL_HOST=127.0.0.1 --MYSQL_TCP_PORT=3306 --MYSQL_DB=zipkin --MYSQL_USER=root --MYSQL_PASS=ok

STORAGE_TYPE : 存储类型
MYSQL_HOST： mysql主机地址
MYSQL_TCP_PORT：mysql端口
MYSQL_DB： mysql数据库名称
MYSQL_USER：mysql用户名
MYSQL_PASS ：mysql密码

在这里插入图片描述
配置好服务端之后，可以在浏览器请求几次。回到数据库查看会发现数据已经持久化到mysql中

下次重启，依然可以看到 历史的链路追踪：
在这里插入图片描述

术语解释

Span

Span：基本工作单元 (相当于一次完整的请求！一次请求对应一个 Span )

Trace

一系列 Spans 组成的一个树状结构，
例如，如果你正在运行一个分布式大数据工程，你可能需要创建一个 Trace。

Span 通过一个 64 位 ID 唯一标识, Trace 以另一个 64 位 ID 表示。可以在控制台中查看！

Annotation

用来即使记录一个事件的存在，一些核心 Annotations 用来定义一个请求的开始和结束:

在这里插入图片描述
在Zipkin Ul页面上, 可以之间对某个服务进行查看: 调用方/提供方响应请求时间…

CS
客户端发起一个请求，这个 Annotation 描述了这个 Span 请求的开始
SS
服务端获得请求并准备开始处理它，如果将其 ss 减去 cs 时间戳便可得到网络延迟
SF
表明请求处理的完成(当请求返回客户端)，如果 sf 减去 ss 时间戳便可得到服务端需要的处理请求时间
CF
表明 Span 的结束，客户端成功接收到服务端的回复,
如果 cf 减去 cs 时间戳便可得到客户端从服务端获取回复的所有所需时间

免责声明：本站所有文章内容,图片，视频等均是来源于用户投稿和互联网及文摘转载整编而成，不代表本站观点，不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益，请在线联系站长,一经查实,本站将立刻删除。本文来自网络,若有侵权，请联系删除，如若转载，请注明出处：https://yundeesoft.com/10095.html

服务链路追踪

服务链路追踪

为什么需要服务追踪

Sleuth概述

简介

服务追踪说明

Sleuth链路追踪入门

依赖：

.yml 配置文件

启动微服务，调用之后，我们可以在控制台观察到sleuth的日志输出。

Zipkin的概述

Zipkin 的基础架构，它主要由 4 个核心组件构成：

Zipkin Server的部署和配置

Zipkin Server下载

启动

默认Zipkin Server的请求端口为 9411

客户端Zipkin + Sleuth整合

客户端添加依赖

客户端配置文件

测试：

链路追踪Sleuth-Zipkin与Mysql数据的持久化:

Zipkin持久化数据库！ Mysql

启动Zipkin Server (附带数据库)

术语解释

Span

Trace

Annotation

相关推荐

发表回复

默认Zipkin Server的请求端口为 `9411`

Zipkin持久化数据库！ `Mysql`