实际使用动态线程池框架dynamic-tp
2024年7月21日
文章目录
1 背景
前段时间新入职了一家公司,组长看我已经有点开发年头了,委任给我一个大活,想让我可以监控任务队列,以及线程池的其他参数,如果有修改、监控到异常则需要进行告警,并且支持实施修改线程池参数。
2 明确任务范围
首先并不是为了强行使用动态线程池框架而使用他,使用它的原因是我们的需求就是:
- 实时监控线程池参数
- 修改实时监控线程池参数的一些状态
- 以及进行及时的告警
- 做到实时修改我们的线程池参数
虽然JDK8可以做到通过方法直接修改线程池参数。但是如果自己手写的话则会浪费很多时间。为了避免重复造轮子,我决定及时使用开源框架。
2.1 技术选型
当然也不是非得使用dynamic-tp不可,首先我们需要看行业中有没有合适的框架或者思路供我们选择,我们发现了这个框架
这个美团技术团队对动态线程池该做什么的功能架构,这刚好和我们的需求不谋而合
此时行业中比较好的开源框架有这两个,dynamic-tp和hippo4j,hoppo4j架构是C/S模式,所以需要新增一个hippo4j服务端,那么如果需要一个线上配置环境修改配置的话,那么hippo4j会好一点,我们目前没有这个需求,所以会使用dynamic-tp,直接引用即可,并且通过集成到自己的配置中心就好了(当然看业务需求是怎么样的,毕竟hippo4j在GitHub上的star数量比dynamictp多一些)
2.2 引入dynamic-tp
(具体请看dynamic-tp的官网操作)
-
我们是使用的nacos作为配置中心和服务发现中心,所以需要引入对应的nacos包
-
dynamic-tp只能使用注解强化Java和spring的自带线程池,所以我们只使用配置文件的方式将业务需要使用的线程池放到Dtp注册器里面
-
在原有的需要放入线程操作的代码中放一下对应的Dtp注册器里面的线程池进行替换
2.引入时产生的问题
-
我们需要自定义告警信息,如果使用自带的wechat提醒或者钉钉提醒,只是通过机器人进行提醒,我们需要使用自己的API
我们使用了自己的API进行了解决,并且使用Java SPI进行了服务提供
-
使用自定义告警信息,涉及到了API,但是自己的API需要从spring的IOC容器里面获取,但是自定义的告警通知是无法拿到的
通过@dependOn解决了这个问题
-
我们想使用自定义的拒绝策略
使用Java SPI进行了拒绝策略的自定义
-
使用dynamic-tp需要考虑到一些公共的修改,比如我们的wechat自定义提醒,自定义拒绝策略,每一次都引入再添加共同的代码文件比较麻烦
我们进行了二次封装,再二次封装的代码中加入了这些修改,这样其他微服务使用dynamic-tp框架时候可以直接使用我们的二次封装的框架
我们并没有使用@import等注解,而是在引入后使用ComponentScan注解主动扫描的
2.1 一些遗憾
- 使用的自定义告警、拒绝策略,则需要使用Java spi进行服务提供与发现,不能使用spring的自动装配
- 只有Java或者spring自带的线程池可以被使用注解强化,用处不大,反而是如果可以使用注解在ThreadPoolExecutor的话则对我们帮助很大
当然,dynamic-tp本身我是很喜欢的,他帮我提前造好了轮子,提升了我们的开发效率。
3.参数怎么跟随业务修改?
线程池参数并不是一成不变的,后续肯定会随着业务的需要进行修改。修改之前需要考虑一下是否有资源没有用到,有时候就是会出现资源没有使用全(如LB没有重定向好)导致的资源紧张。
修改线程池参数一般只会修改核心线程数、最大线程数、任务队列这几个信息。线程池执行情况与任务类型相关性较大,IO 密集型和 CPU 密集型的任务运行起来的情况差异非常大,所以一般我们每个微服务会有两个线程池,一个用于做IO密集型,一个用于做CPU密集型任务,这两个线程池的参数调试肯定是不一样的
具体的方法有这几种:
-
根据经验猜
-
此处我放一张行业内比较认可的图片
这几种方式见仁见智
-
根据方法二的调参进行修改,同时使用动态线程池实时监控线程池负载,如果线程池逐步正常,则表明修改后的参数可以满足业务需求