第11章 分布式服务跟踪: Spring Cloud Sleuth

  通常一个由客户端发起的请求在后端系统中会经过多个不同的微服务调用来协同产生最后的请求结果, 在复杂的微服务架构系统中, 几乎每一个前端请求都会形成一条复杂的分布式服务调用链路, 在每条链路中任何一个依赖服务出现延迟过高或错误的时候都有可能引起请求最后的失败。这时候,对于每个请求, 全链路调用的跟踪就变得越来越重要, 通过实现对请求调用的跟踪可以帮助我们快速发现错误根源以及监控分析每条请求链路上的性能瓶颈等。Spring Cloud Sleuth 提供了 一套完整的解决的分布式服务跟踪问题的方案

pom.xml 中增加下面的依赖

<parent>
  <groupid>org.springframework.boot</groupid>
  <artifactid>spring-boot-starter-parent</artifactid>
  <version>l.3.7.RELEASE</version>
  <relativePath/>
</parent>
<dependency>
  <groupid>org.springframework.boot</groupid>
  <artifactid>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
  <groupid>org.springframework.cloud</groupid>
  <artifactid>spring-cloud-starter-eureka</artifactid>
</dependency>
<dependency>
  <groupid>org.springframework.cloud</groupid>
  <artifactid>spring-cloud-starter-ribbon</artifactid>
</dependency>
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupid>org.springframework.cloud</groupid>
      <artifactid>spring-cloud-dependencies</artifactid>
      <version>Brixton.SRS</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

在application.properties 中,将 eureka.client.serviceUrl.defaultZone参数指向 eureka-server 的地址

spring.application.name=trace-1
server.port=9101
eureka.client.serviceUrl.defaultZone=http://localhost:llll/eureka/ 

跟踪原理

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

原文地址:https://www.cnblogs.com/hzzjj/p/10291685.html

时间: 2024-08-26 05:13:28

第11章 分布式服务跟踪: Spring Cloud Sleuth的相关文章

Spring Cloud Sleuth + zipkin 实现服务追踪

服务追踪 Spring Cloud Sleuth实现了一种分布式的服务链路跟踪解决方案,通过使用Sleuth可以让我们快速定位某个服务的问题. 官方文档地址如下: http://cloud.spring.io/spring-cloud-static/spring-cloud-sleuth/2.0.1.RELEASE/single/spring-cloud-sleuth.html 一些概念: Span,Span是基本的工作单元.Span包括一个64位的唯一ID,一个64位trace码,描述信息,时

Spring Cloud构建微服务架构 分布式服务跟踪(跟踪原理)【Dalston版】

通过上一篇<分布式服务跟踪(入门)>的例子,我们已经通过Spring Cloud Sleuth往微服务应用中添加了实现分布式跟踪具备的基本要素.下面通过本文来详细说说实现分布式服务跟踪的一些要点. 分布式系统中的服务跟踪在理论上并不复杂,它主要包括下面两个关键点: 为了实现请求跟踪,当请求发送到分布式系统的入口端点时,只需要服务跟踪框架为该请求创建一个唯一的跟踪标识,同时在分布式系统内部流转的时候,框架始终保持传递该唯一标识,直到返回给请求方为止,这个唯一标识就是前文中提到的Trace ID.

【Spring Cloud】Spring Cloud之Spring Cloud Sleuth,分布式服务跟踪(1)

一.Spring Cloud Sleuth组件的作用 为微服务架构增加分布式服务跟踪的能力,对于每个请求,进行全链路调用的跟踪,可以帮助我们快速发现错误根源以及监控分析每条请求链路上的性能瓶颈等. 二.项目中如何引入Spring Cloud Sleuth组件1)增加spring-cloud-starter-sleuth依赖 <!-- sleuth--> <dependency> <groupId>org.springframework.cloud</groupId

Spring Cloud构建微服务架构 分布式服务跟踪(抽样收集)【Dalston版】

通过Trace ID和Span ID已经实现了对分布式系统中的请求跟踪,而这些记录的跟踪信息最终会被分析系统收集起来,并用来实现对分布式系统的监控和分析功能,比如:预警延迟过长的请求链路.查询请求链路的调用明细等.此时,我们在对接分析系统时就会碰到一个问题:分析系统在收集跟踪信息的时候,需要收集多少量的跟踪信息才合适呢? 理论上来说,我们收集的跟踪信息越多就可以更好的反映出系统的实际运行情况,并给出更精准的预警和分析,但是在高并发的分布式系统运行时,大量的请求调用会产生海量的跟踪日志信息,如果我

跟我学SpringCloud | 第十一篇:使用Spring Cloud Sleuth和Zipkin进行分布式链路跟踪

SpringCloud系列教程 | 第十一篇:使用Spring Cloud Sleuth和Zipkin进行分布式链路跟踪 Springboot: 2.1.6.RELEASE SpringCloud: Greenwich.SR1 如无特殊说明,本系列教程全采用以上版本 在分布式服务架构中,需要对分布式服务进行治理--在分布式服务协同向用户提供服务时,每个请求都被哪些服务处理?在遇到问题时,在调用哪个服务上发生了问题?在分析性能时,调用各个服务都花了多长时间?哪些调用可以并行执行?-- 为此,分布式

spring cloud微服务分布式云架构 - Spring Cloud集成项目简介

Spring Cloud集成项目有很多,下面我们列举一下和Spring Cloud相关的优秀项目,我们的企业架构中用到了很多的优秀项目,说白了,也是站在巨人的肩膀上去整合的.在学习Spring Cloud之前大家必须了解一下相关项目,希望可以帮助到大家. Spring Cloud Config 配置管理工具包,让你可以把配置放到远程服务器,集中化管理集群配置,目前支持本地存储.Git以及Subversion. Spring Cloud Bus ?事件.消息总线,用于在集群(例如,配置变化事件)中

(三)spring cloud微服务分布式云架构 - Spring Cloud集成项目简介

Spring Cloud集成项目有很多,下面我们列举一下和Spring Cloud相关的优秀项目,我们的企业架构中用到了很多的优秀项目,说白了,也是站在巨人的肩膀上去整合的.在学习Spring Cloud之前大家必须了解一下相关项目,希望可以帮助到大家. Spring Cloud Config 配置管理工具包,让你可以把配置放到远程服务器,集中化管理集群配置,目前支持本地存储.Git以及Subversion. Spring Cloud Bus ?事件.消息总线,用于在集群(例如,配置变化事件)中

微服务选择Spring Cloud还是Dubbo?

点击关注 异步图书,置顶公众号 每天与你分享 IT好书 技术干货 职场知识 参与文末话题讨论,每日赠送异步图书. --异步小编 在阿里巴巴的生态中,微服务逐渐成为主要的服务形态,伴随着容器化的日臻成熟,大量的分布式.领域驱动设计的微服务被快速开发和部署,服务间呈现出搭积木的能力,使不同的业务通过重新组合数个微服务,就能实现新的业务场景.借助成熟的底层集团中间件,天然地支持微服务所需的动态扩缩.服务发现.全链路日志分析等能力.以阿里巴巴达摩院语音对话平台为例,对话服务.理解服务.问答服务,以及对话

spring cloud 入门系列八:使用spring cloud sleuth整合zipkin进行服务链路追踪

好久没有写博客了,主要是最近有些忙,今天忙里偷闲来一篇. =======我是华丽的分割线========== 微服务架构是一种分布式架构,微服务系统按照业务划分服务单元,一个微服务往往会有很多个服务单元,一个请求往往会有很多个单元参与,一旦请求出现异常,想要去定位问题点真心不容易,因此需要有个东西去跟踪请求链路,记录一个请求都调用了哪些服务单元,调用顺序是怎么样的以及在各个服务单元处理的时间长短.常见的服务链路追踪组件有google的dapper.twitter的zipkin.阿里的鹰眼等,它们