基于Ko-time的Springboot单体化调用链追踪实践

这篇具有很好参考价值的文章主要介绍了基于Ko-time的Springboot单体化调用链追踪实践。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

前言

一、关于Ko-Time

1、是什么?

 2、ko-time更新时间线

二、Ko-time怎么用?

1、依赖引入

2、配置集成

3、权限放行

三、链路追踪 

1、系统运行

 2、链路追踪

 3、长时间调用模拟

 总结


前言

        熟悉微服务的老司机一定了解,在微服务模式下,在一次调用链路中,可能设计到多个微服务,如果在线上,某个微服务出现故障,如何快速定位故障所在额微服务呢?解决思路是可以使用链路追踪技。通常在链路追踪领域有以下的一些备选技术,比如可以用由大众点评开源,基于Java开发的实时应用监控平台Cat,包括实时应用监控,业务监控 。集成 方案是通过代码埋点的方式来实现监控,比如: 拦截器,过滤器等。 对代码的侵入性很大,集成成本较高。风险较大。也可以采用韩国人开源的基于字节码注入的调用链分析,以及应用监控分析工具Pinpoint。它的特点是支持多种插件,UI功能强大,接入端无代码侵入。 还可以采用本土开源的基于字节码注入的调用链分析以及应用监控分析工具SkyWalking。特点是支持多种插件,UI功能较强,接入端无代码侵入。目前已加入Apache孵化器--开源。

        上述场景是解决微服务的链路追踪的,那么一般采用单体化架构的开发模式时,在小场景下,您是如何定位代码的性能,在出现问题时,是通过log+调用起始时间进行分段汇总吗?这样费时又费力,主要还不直观。那么怎么在Springboot架构下进行单体开发时,快速集成单体化模式下的链路追踪呢?本文介绍一款开源的基于Java开发的监控组件,同时详细讲解如何在你的项目中进行深度集成,最后给出详细的实现案例。不仅方便进行调用链路追踪,还自带可视化UI,甚至有报警配置,喜欢的朋友可以前来看看。

一、关于Ko-Time

1、是什么?

        koTime是一个轻量级的springboot项目性能分析工具,通过追踪方法调用链路以及对应的运行时长快速定位性能瓶颈,ko-time gitee地址。

  • ✅ 实时监听方法,统计运行时长
  • ✅ web展示方法调用链路,瓶颈可视化追踪
  • ✅ 追踪系统异常,精确定位到方法
  • ✅ 接口超时邮件通知,无需实时查看
  • ✅ 线上热更新:无需重启更新代码
  • ✅ 线程管理:线程实时统计与状态查看
  • ✅ 使用简单,无技术学习成本
  • ✅ pom依赖即可,无代码侵入,无多余部署成本

基于Ko-time的Springboot单体化调用链追踪实践,java,spring boot,ko-time单体化监控

 2、ko-time更新时间线

基于Ko-time的Springboot单体化调用链追踪实践,java,spring boot,ko-time单体化监控

二、Ko-time怎么用?

1、依赖引入

 <dependency>
    <groupId>cn.langpy</groupId>
    <artifactId>ko-time</artifactId>
    <version>2.4.1</version>
  </dependency>
  <!--阿里云maven仓库更新会慢一两天左右,拉取失败的切换到maven中央仓库-->

2、配置集成

        本次代码集成以ruoyi单体化架构集成为例,ruoyi的配置文件主要配置在yml中,需要进行一定的配置才能运行。官网提供的是基于properties的配置模式,下面提供yml的配置转换,具体代码如下:

ko-time: 
  # 是否开启koTime,默认开启,当为false时,关闭koTime 
  enable: true
  # 是否开启控制输出,默认false
  log-enable: false    
  # 语言(english/chinese)默认chinese
  language: chinese  
  # 时间阈值,用于前端展示,大于阈值显示红色,小于阈值显示绿色,默认800
  threshold: 800.0   
  # context-path: http://localhost:80 # 前端页面调用接口的上下文环境,无法自动获取时可手动配置,一般情况切记不要配置   v2.0.1开始支持  
  exception-enable: true # 是否开启异常检测,默认为false,开启后会对方法内部抛出的异常进行统计 v2.0.0开始支持  
  # 是否开启认证,默认为false,开启后需要登录才能访问调用链路 v2.0.2开始支持
  auth-enable: false   
  # 登录用户 v2.0.2开始支持
  #user-name: admin   
  # 登录密码 v2.0.2开始支持 
  #password: 123456  
  # 使用静态的token值进行认证访问(/koTime?kotoken=xxx) v2.3.7开始支持,该模式和user-name认证模式二选一 
  #static-token: xxxx 
  # 是否开启入参组合分析 默认开启 v2.0.8开始支持 双击方法节点即可看到效果
  param-analyse: true  
  # 启动时是否删除过往数据 默认false v2.2.3开始支持
  data-reset: false 
  # 调用信息存储线程数(为了不影响项目本身性能,链路存储异步进行),默认2,该值并非越大越好,瓶颈取决于数据库性能和服务器配置,尽可能少占用项目资源为上  v2.2.0-BETA开始支持
  thread-num: 2 
  # 丢弃率(0-1) 同一个方法在多次连续调用时,耗时差距并不大,为了存储的IO性能考虑,可以随机丢弃一部分耗时数据。默认30% v2.2.5开始支持
  discard-rate: 0.3 
  # 登录超时时间考虑 默认43200s(12个小时) v2.3.0开始支持
  auth-expire: 43200 
  # 获取最新版本通知开关 在页面上可以看到 默认true v2.3.3开始支持
  version-notice: true 
  #需要监测的范围,是链路包含的范围,不仅仅是接口层,参考aop的@pointcut
  pointcut: execution(public * com.ruoyi.project..*.*(..)) 

        请注意,以上部分参数的值请根据具体的代码进行修改,请不要直接复制,以免造成必须要的误解。比如,在这里ko-time的web-ui访问页面的访问权限我已经设置关闭,实际项目中一定要打开,并且设置一个用户名和密码。在这里可以配置代码的时间阈值,这里采用默认值,单位是毫秒。最后需要注意的是,由于这种单体化切入的模式都是采用AOP模式,因此必须要设置合理的切入点。见配置文件中的pointcut参数配置,这里我选择监控的是com.ruoyi.project下的任意方法。

关于切入配置参考如下:

假设项目的包路径为:

com.huoyo.demo
        |-controller
        |-service
        |-mapper
        |-others
            |-other1
            |-other2
            |-Test.java
        

  想要切cn.langpy.demo下面的所有方法(包括子包中的),可以写:

execution(public * com.huoyo.demo..*.*(..)) #切记,是两个点.

只想要切cn.langpy.demo.controller下面的类的所有方法(不包括子包的),可以写:

execution(public * com.huoyo.demo.controller.*.*(..)) #切记,是一个点.

只想要切cn.langpy.demo.others下面的类的所有方法(不包括other1和other2下面的),可以写:

execution(public * com.huoyo.demo.others.*.*(..))

只想要切cn.langpy.demo.others下面的类的所有方法(包括other1和other2),可以写:

execution(public * com.huoyo.demo.others..*.*(..))

如果想排除某些类如Test.class,可以

execution(public * com.huoyo.demo.others..*.*(..)) && !execution(public * com.huoyo.demo.others.Test(..))

3、权限放行

        由于系统配置的权限,因此要在后台系统中将ko-time的访问权限放开。在ShiroConfig中进行配置。

//设置/koTime允许匿名访问
filterChainDefinitionMap.put("/koTime/**","anon");
filterChainDefinitionMap.put("/koTime", "anon");

三、链路追踪 

1、系统运行

        不管是微服务的链路追踪或者单体化链路追踪,其原理都是需要进行服务和接口的调用,所以我们模拟进行服务访问。点击登录和进行一些方法的操作。

基于Ko-time的Springboot单体化调用链追踪实践,java,spring boot,ko-time单体化监控

 2、链路追踪

        在进行了页面访问之后,在浏览器中输入http://ip:port/koTime就可以访问到链路追踪的web界面。这里就详细的列出了调用信息,比如接口总数,列表,异常列表,线程列表。

基于Ko-time的Springboot单体化调用链追踪实践,java,spring boot,ko-time单体化监控

基于Ko-time的Springboot单体化调用链追踪实践,java,spring boot,ko-time单体化监控

基于Ko-time的Springboot单体化调用链追踪实践,java,spring boot,ko-time单体化监控

 3、长时间调用模拟

为了模拟实际的访问慢的接口,我们在代码中进行了休眠设置(线上代码不建议如此)。

/**
     * 修改子元素关系
     * 
     * @param deptId 被修改的部门ID
     * @param newAncestors 新的父ID集合
     * @param oldAncestors 旧的父ID集合
     */
    public void updateDeptChildren(Long deptId, String newAncestors, String oldAncestors)
    {
    	try {
	    	for(int i =0;i<5;i++) {
				Thread.sleep(200);
	    	}
    	} catch (InterruptedException e) {
		}
        List<Dept> children = deptMapper.selectChildrenDeptById(deptId);
        for (Dept child : children)
        {
            child.setAncestors(child.getAncestors().replaceFirst(oldAncestors, newAncestors));
        }
        if (children.size() > 0)
        {
            deptMapper.updateDeptChildren(children);
        }
    }

基于Ko-time的Springboot单体化调用链追踪实践,java,spring boot,ko-time单体化监控

基于Ko-time的Springboot单体化调用链追踪实践,java,spring boot,ko-time单体化监控

 总结

        以上就是本文的主要内容,本文介绍一款开源的基于Java开发的监控组件,同时详细讲解如何在你的项目中进行深度集成,最后给出详细的实现案例。不仅方便进行调用链路追踪,还自带可视化UI,甚至有报警配置,喜欢的朋友可以前来看看。更多的功能,希望朋友们一起来挖掘。行文仓促,如有不当之处,欢迎评论区留言批评。文章来源地址https://www.toymoban.com/news/detail-617329.html

到了这里,关于基于Ko-time的Springboot单体化调用链追踪实践的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • springboot远程调用常见问题feign.RetryableException: Connection timed out

    1,远程调用基本介绍 1.1,@FeignClient标签的常用属性如下:     name:指定FeignClient的名称,如果项目使用了Ribbon,name属性会作为微服务的名称,用于服务发现     url: url一般用于调试,可以手动指定@FeignClient调用的地址     path: 定义当前FeignClient的统一前缀,当我们项目中

    2024年02月02日
    浏览(48)
  • springboot单体项目转springcloud保姆级教程

    当学习吧,我有个开源项目是魔改了ruoyi-vue的,加入了我喜欢的技术以及删除了一些我认为一个系统并不一定是需要的功能,有兴趣的朋友可以先看下这个单体项目,可以更加理解等会儿要演示的流程: 不废话直接流程。 这是原本的单体项目项目结构: 首先聚合项目大家应

    2024年02月02日
    浏览(27)
  • 【微服务部署】07-调用链追踪

    1. SkyWalking架构图 Receiver是SkyWalking的入口,支持gRPC和HTTP协议。 SkyWalking内部有分析和查询两个部分 存储方面SkyWalking支持Elasticsearch和MySql,H2等数据库 2. 代码集成SkyWalking 包引用:SkyAPM.Agent.AspNetCore/SkyAPM.Transport.Grpc/SkyAPM.Transport.Grpc.Protocol 应用程序根目录放置skyapm.json文件 程序

    2024年02月10日
    浏览(26)
  • 【SpringBoot】Spring Boot 单体应用升级 Spring Cloud 微服务

    Spring Cloud 是在 Spring Boot 之上构建的一套微服务生态体系,包括服务发现、配置中心、限流降级、分布式事务、异步消息等,因此通过增加依赖、注解等简单的四步即可完成 Spring Boot 应用到 Spring Cloud 升级。 Spring Boot 应用升级为 Spring Cloud Cloud Native 以下是应用升级 Spring Clou

    2024年02月02日
    浏览(32)
  • springboot 集成caffeine单体缓存两种方式及算法简介 (注解/手动)

           Caffeine 是基于 JAVA 8 的高性能缓存库。并且在 spring5 (springboot 2.x) 后,spring 官方放弃了 Guava,而使用了性能更优秀的 Caffeine 作为默认缓存组件。        Caffeine 因为使用了  Window-TinyLFU  缓存淘汰策略,提供了一个 近乎最佳的命中率 。综合了 LRU 和 LFU 算法的长处,

    2024年02月03日
    浏览(34)
  • 【SkyWalking】分布式服务追踪与调用链系统

    SkyWalking是一个开源的观测平台,官网:Apache SkyWalking; 可监控: 分布式追踪调用链 、jvm内存变化、监控报警、查看服务器基本配置信息。 在整个skywalking的系统中,有三个角色: 1.skywalking agent 和业务系统(jar)关联在一起 ,负责收集各种监控数据; 2.skywalking oapservice负责处

    2024年02月11日
    浏览(33)
  • 【Spring Cloud】基于 Feign 实现远程调用,深入探索 Feign 的自定义配置、性能优化以及最佳实践方案

    在微服务架构中,服务之间的通信是至关重要的,而远程调用则成为实现这种通信的一种常见方式。在 Java 中,使用 RestTemplate 是一种传统的远程调用方式,但它存在一些问题,如代码可读性差、编程体验不一致以及参数复杂URL难以维护等。 在本文中,我们将探讨如何通过使

    2024年02月04日
    浏览(37)
  • 【企业级SpringBoot单体项目模板 】——Mybatis-plus自动代码生成

    😜 作           者 :是江迪呀 ✒️ 本文 : SpringBoot项目模版 、 企业级 、 模版 ☀️ 每日   一言 : 我们之所以这样认为,是因为他们这样说。他们之所以那样说,是因为他们想让我们那样认为。所以实践才是检验真理的唯一准则。 上回 我们说了一些开发规范

    2024年02月07日
    浏览(35)
  • 在SpringBoot中基于CanvasLabel的地震基础信息展示实践

    目录 前言 一、数据库设计 1、数据库设计 2、sql脚本  3、数据记录 二、SpringBoot后台设计与实现 1、Mapper访问层及实体定义 2、Service层实现 3、控制层实现 三、地震信息展示 1、展示数据接入   2、最终效果 总结         在上一篇博客中,对于在Leaflet中进行矢量数据进行

    2024年01月25日
    浏览(28)
  • 1.3 eureka+ribbon,完成服务注册与调用,负载均衡源码追踪

    本篇继先前发布的1.2 eureka注册中心,完成服务注册的内容 。 目录 环境搭建 采用eureka+ribbon的方式,对多个user服务发送请求,并实现负载均衡 负载均衡原理 负载均衡源码追踪 负载均衡策略 如何选择负载均衡策略? 饥饿加载 复制(补充) 给order模块和user模块建立独立的数

    2024年02月14日
    浏览(35)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包