微服务链路追踪Spring Cloud Sleuth整合Zipkin解析

目录
  • 前言
  • 何为调用链路
  • Zipkin + Sleuth
    • Zipkin
    • Spring Cloud Sleuth
    • Zipkin启动
    • 引入jar
    • 服务调用测试
  • 总结

前言

如果在开发过程中,你还在靠查看服务器日志来寻找服务与服务之间的报错信息,那么这篇一定要来看下,通常在我们开发环境自测的时候,我们会将代码发布到开发环境,然后无论是通过postMan请求,还是通过页面请求,遇到报错的信息,我们都会去服务器上去看时实的日志,来寻找报错信息;

如果涉及到多个服务调用,这个时候会登陆多个服务器去查看服务的报错信息,这仅仅是在我们开发环境自测的时候我们会去这么操作;如果是在生产环境,还依靠这种方式,那么多少就会显得比较low了,这时候我们就要快速的定位到故障服务,就要引入“服务调用链路”的概念。

何为调用链路

一个大型分布式微服务系统往往由若干个微服务组成,这些微服务部署在若干个服务器上,为了实现高可用还会采取集群的方式,若干个服务相互调用就形成了调用链网络。

服务之间的调用出现异常、超时、宕机,某一个服务出现这样的情况,都会导致整个调用链路出现问题, 在出现这样问题的时候就要及时的解决,来避免整个业务系统的不可用,这个时候就必须快速定位问题。

Zipkin + Sleuth

作为为微服务提供调用链路支持的其实有很多组件,包括SkyWalking、CAT、Pinpoint、Zipkin + Sleuth,这些组件的实现方式、接入方式、颗粒度、traceid查询等方面可能有不同,但是最终目的其实都一样,就是把请求的链路记录下来供开发人员排错参考,这里我因为我项目使用的是Spring Cloud,协议也是使用的http,所选择的是 Spring Cloud Sleuth更加匹配项目,集成也相对容易。

Zipkin

Zipkin分布式追踪系统,简单的说在一个西瓜摊,里面的瓜有大有小、有熟有生、有好有坏,所有的瓜都混杂在一起,我们很难去找到比较合适的瓜买走, Zipkin所做的就是追踪分析,找到好的瓜,然后将坏的瓜卖不出去的瓜进行剔除。

这离涉及到几个概念,也是链路追踪的核心。

  • Traceld:用来标记服务调用链的标记,包括所有在请求链中的服务,都使用的一个链路追踪ID
  • SpanId:区域ID,调用链中某个服务的专属ID,无论是调用者和被调用者都会产生自己的SpanId
  • ParentId:父级ID,调用者的生成的SpanId,在去请求下游服务,SpanId会成为下游服务的ParentId,用来标记上下游的关系。

Spring Cloud Sleuth

可以理解为基于Zipkin的一个封装,sleuth可以记录调用的情况,而Zipkin可以收集这些调用信息。

Zipkin启动

下面基于Spring Cloud Sleuth整合Zipkin

docker run zipkin:

docker run -d  -p 9411:9411 openzipkin/zipkin

Zipkin 启动完成

引入jar

使用的框架版本 spring-cloud.version:Hoxton.SR4 spring-boot.version:2.2.6.RELEASE

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

引入sleuth和zipkin,nacos配置

sleuth:
    enabled: true
    sampler:
      rate: 100
 # 设置 Sleuth 收集信息的百分比
zipkin:
    sender:
      type: web
    base-url: http://127.0.0.1:9411/

️ zipkin:sender:type: web (这里type类型可以支持多种,web、kafka、rabbit、activemq都可以支持),这里只做web类型的演示。

服务调用测试

System2 服务提供feig接口,供system服务调用

@FeignClient(contextId = "iTestServiceClient", value = "Lxlxxx-system2", fallbackFactory = TestServiceFallbackFactory.class)
public interface ITestServiceClient {
    /**
     * 服务调用测试方法
     * @return
     */
    @GetMapping("/test/method")
    public String testRequestMethod();
}

system服务调System2的feign接口

@RestController
@Slf4j
public class TestController {
    @Autowired
    private ITestServiceClient iTestServiceClient;
    @GetMapping("/testMethod")
    public void testMethod(){
        log.info("通过feign调用system2服务~~~~~~~~~");
        iTestServiceClient.testRequestMethod();
    }
}

我这边注册了两个服务 分别是Lxlxxx-system 和 Lxlxxx-system2分服务

Zipkin查看调用情况

总结

由上面可见,可以很清楚的看出微服务之间的调用情况,当然这些调用的日志也是可以通过ES进行持久化的,这样可以保证Zipkin重启后,链路信息不会丢失,这里就不做展示了,有兴趣的朋友也可以将ES集成进去。

当然,Spring Cloud Sleuth 结合 Zipkin不光可以对微服务进行追踪,如果请求量较大也可以集成消息中间件,Sleuth将日志推给MQ,然后Zipkin去MQ队列获取服务调用日志,可以调用链在我们对服务监控、排查问题,起到了至关重要的作用。

以上就是微服务链路追踪Spring Cloud Sleuth整合Zipkin解析的详细内容,更多关于Spring Cloud Sleuth整合Zipkin的资料请关注我们其它相关文章!

(0)

相关推荐

  • SpringCloud Sleuth实现分布式请求链路跟踪流程详解

    目录 1.概念 2.搭建链路监控步骤 2.1.zipkin 2.2.服务提供者 2.3.服务消费者(调用方) 1.概念 Git官网地址:https://github.com/spring-cloud/spring-cloud-sleuth 官网地址:https://spring.io/projects/spring-cloud-sleuth 在微服务框架中,一个由客户端发起的请求在后端系统中会经过多个不同的的服务节点调用来协同产生最后的请求结果,每一个前段请求都会形成一条复杂的分布式服务调用链路

  • java分治思想之ForkJoin详解

    目录 前言 分治思想算法 归并排序 快速排序 Fork/Join ForkJoinPool 构造器 工作窃取法 使用 前言   当我们面对需要同时执行多个任务的情况时,往往需要耗费大量的时间和精力来编写复杂的并发代码.但是有一种技术可以帮助我们轻松地处理这种情况.通过forkJoin,我们可以简单地实现多个任务的并行执行,从而提高应用程序的性能和响应能力.在本文中,我们将深入探讨forkJoin的工作原理和使用方法. 分治思想算法   fork-join模式是基于分治思想的并行计算模式之一.该模

  • SpringCloud_Sleuth分布式链路请求跟踪的示例代码

    目录 一.概述 1.为什么会出现这个技术?需要解决哪些问题? 2.是什么 3.解决 二.搭建链路监控步骤 1.zipkin 2.服务提供者 3.服务消费者(调用方) 4.依次启动eureka7001/8001/80 Spring Cloud Sleuth是一款针对Spring Cloud的分布式跟踪工具.它借鉴了Dapper.Zipkin和HTrace. 特点 将trace Id和 span Id 添加到Slf4J MDC,这样就可以在日志聚合器中从给定的trace或span提取所有日志. 提供

  • Spring Cloud 专题之Sleuth 服务跟踪实现方法

    目录 准备工作 实现跟踪 抽样收集 整合Zipkin 1.下载Zipkin 2.引入依赖配置 3.测试与分析 持久化到mysql 1.创建zipkin数据库 2.启动zipkin 3.测试与分析 在一个微服务架构中,系统的规模往往会比较大,各微服务之间的调用关系也错综复杂.通常一个有客户端发起的请求在后端系统中会经过多个不同的微服务调用阿里协同产生最后的请求结果.在复杂的微服务架构中,几乎每一个前端请求都会形成一条复杂的分布式的服务调用链路,在每条链路中任何一个依赖服务出现延迟过高或错误的时候都

  • Spring Cloud Sleuth 和 Zipkin 进行分布式跟踪使用小结

    目录 什么是分布式跟踪? 分布式跟踪的关键概念 带有SpringCloudSleuth的SpringBoot示例 使用Zipkin可视化跟踪 分布式跟踪允许您跟踪分布式系统中的请求.本文通过了解如何使用 Spring Cloud Sleuth 和 Zipkin 来做到这一点. 对于一个做所有事情的大型应用程序(我们通常将其称为单体应用程序),跟踪应用程序内的传入请求很容易.我们可以跟踪日志,然后弄清楚请求是如何处理的.除了应用程序日志本身之外,我们无需查看其他任何内容. 随着时间的推移,单体应用

  • Spring Cloud Sleuth整合zipkin过程解析

    这篇文章主要介绍了Spring Cloud Sleuth整合zipkin过程解析,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 SpringCloud Sleuth 简介 Spring Cloud Sleuth为Spring Cloud实现了分布式跟踪解决方案. Spring Cloud Sleuth借鉴了Dapper的术语. Span:基本的工作单元.Span包括一个64位的唯一ID,一个64位trace码,描述信息,时间戳事件,key-va

  • 详解spring cloud分布式整合zipkin的链路跟踪

    为什么使用zipkin? 上篇主要写了:spring cloud分布式日志链路跟踪 从上篇中可以看出服务之间的调用,假设现在有十几台服务,那么在查找日志的时候比较繁琐.复杂,而且在查看调用的时候也会像蜘蛛网一样,量太大. 这时候zipkin可以把链路调用整个过程给升级起来,只需要到一个地方去查找,就可以知道哪一步出错. zipkin也分为服务器和客户端,服务器就是zipkin,微服务就是客户端. 首先,建立服务器zipkin 在此服务build.gradle加上zipkin的依赖: compil

  • 微服务搭建集成Spring Cloud Turbine详解

    1.概述 本文中,我将向你介绍Spring Cloud Netflix Turbine.它将多个Hystrix Metrics Streams 聚合为一个,以便显示在一个仪表板视图中. 简要介绍Hystrix . 在微服务架构中,我们有许多小应用程序相互通信以完成请求.这些下游服务有可能无法正确响应或完全失败.为了防止发生级联故障,我们为微服务设置了Hystrix回退机制. 每个实现Hystrix的微服务都可以选择公开Hystrix Metrics Streams(通过actuator端点/hy

  • spring cloud gateway整合sentinel实现网关限流

    这篇文章主要介绍了spring cloud gateway整合sentinel实现网关限流,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 说明: sentinel可以作为各微服务的限流,也可以作为gateway网关的限流组件. spring cloud gateway有限流功能,但此处用sentinel来作为替待. 说明:sentinel流控可以放在gateway网关端,也可以放在各微服务端. 1,以父工程为基础,创建子工程 2,添加pom依赖

  • Spring Cloud Gateway整合sentinel 实现流控熔断的问题

    目录 一.什么是网关限流: 二.gateway 整合 sentinel 实现网关限流: 三.sentinel 网关流控规则的介绍: 3.1.网关流控规则: 3.2.API 分组管理: 四.sentinel 网关流控实现的原理: 五.网关限流了,服务就安全了吗? 六.自定义流控异常消息: 一.什么是网关限流: 在微服务架构中,网关层可以屏蔽外部服务直接对内部服务进行调用,对内部服务起到隔离保护的作用,网关限流,顾名思义,就是通过网关层对服务进行限流,从而达到保护后端服务的作用. Sentinel

  • Spring Cloud Gateway 整合 knife4j 聚合接口文档功能

    当系统中微服务数量越来越多时,如果任由这些服务散落在各处,那么最终管理每个项目的接口文档将是一件十分麻烦的事情,单是记住所有微服务的接口文档访问地址就是一件苦差事了.当如果能够将所有微服务项目的接口文档都统一汇总在同一个可视化页面,那么将大大减少我们的接口文档管理维护工作,为此,我们可以基于 Spring Cloud Gateway 网关 + nacos + knife4j 对所有微服务项目的接口文档进行聚合,从而实现我们想要的文档管理功能 注:本案例需要 springboot 提前整合 nac

  • Spring Cloud Alibaba整合Sentinel的实现步骤

    一.需求 实现一个简单的 整合 sentinel,不涉及sentinel的用法 二.实现步骤 1.下载 sentinel dashboard https://github.com/alibaba/Sentinel/releases 注意: 默认会启动8080端口,如果端口冲突,可以在启动命令上加入 -Dserver.port=新端口 默认用户名和密码[sentinel/sentinel] 启动控制台可用的配置项 2.服务提供者和消费者引入sentinel依赖 <dependency> <

  • Spring Cloud Feign组件实例解析

    这篇文章主要介绍了Spring Cloud Feign组件实例解析,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 采用Spring Cloud微服务框架后,经常会涉及到服务间调用,服务间调用采用了Feign组件. 由于之前有使用dubbo经验.dubbo的负载均衡策略(轮训.最小连接数.随机轮训.加权轮训),dubbo失败策略(快速失败.失败重试等等), 所以Feign负载均衡策略的是什么? 失败后是否会重试,重试策略又是什么?带这个疑问,查了

  • 详解spring cloud config整合gitlab搭建分布式的配置中心

    在前面的博客中,我们都是将配置文件放在各自的服务中,但是这样做有一个缺点,一旦配置修改了,那么我们就必须停机,然后修改配置文件后再进行上线,服务少的话,这样做还无可厚非,但是如果是成百上千的服务了,这个时候,就需要用到分布式的配置管理了.而spring cloud config正是用来解决这个问题而生的.下面就结合gitlab来实现分布式配置中心的搭建.spring cloud config配置中心由server端和client端组成, 前提:在gitlab中的工程下新建一个配置文件config

随机推荐