• 35648

    文章

  • 23

    评论

  • 20

    友链

  • 最近新加了很多技术文章,大家多来逛逛吧~~~~
  • 喜欢这个网站的朋友可以加一下QQ群,我们一起交流技术。

【niubi-job——一个分布式的任务调度框架】----niubi-job这下更牛逼了!

欢迎来到阿八个人博客网站。本 阿八个人博客 网站提供最新的站长新闻,各种互联网资讯。 喜欢本站的朋友可以收藏本站,或者加QQ:我们大家一起来交流技术! URL链接:https://www.abboke.com/jsh/2019/0612/2974.html

niubi-job迎来第一次重大优化

  

  niubi-job是一款专门针对定时任务所设计的分布式任务调度框架,它可以进行动态发布任务,并且有超高的可用性保证。

  有多少人半夜被叫起来查BUG,结果差到最后发现,是因为某个定时任务挂了导致出了问题?

  有了niubi-job,你再也不用担心这个问题!

  又有多少人因为要发布一个新的定时任务,为了不影响线上的运行,只能等到半夜再去发布应用?

  有了niubi-job,你可以随时发布你的定时任务而且不会影响当前任务的运行!

  是不是很兴奋呢?

  还有更兴奋的呢,那就是niubi-job发布了全新的0.9.4.2版本,这可是niubi-job历史上一次重大版本的变更,前后共历时将近一个月才完成。虽然这中间由于本人换工作,拖延了一些时间,但niubi-job从零到有,整个第一个版本的开发才花了本人大约三个星期的时间,而本次变更就花费了一个月的时间,可见这一次变更有多么重大了吧。

  接下来,咱们就看看这个版本都有哪些优化吧。

  

0.9.4.2最大的优化——性能优化

  

  niubi-job发布任务的方式是在Web控制台上传jar包,在Web控制台上面操作任务的启动、暂停以及重启。

  而之前niubi-job的设计有一个缺陷,那就是每一个jar包都会对应一个线程池(默认线程池的大小为10个线程)。一种可能的情况是,你先发布了task-1.0.jar,里面包含了1到10一共十个任务。后来你修改了1号任务,于是你上传了task-1.1.jar,这个时候,你的task-1.0.jar对应了一个线程池,里面跑了9个任务,而你的task-1.1.jar也对应了一个线程池,里面只跑了一个任务。

  更可怕的是,你先后陆续把10个任务都发布了一遍,一直到task-1.10.jar。这个时候,将会被启动10个线程池(共计100个线程),但是每一个线程池只跑一个任务(有90个线程在空转),这是一种很大的资源浪费。

  第一次niubi-job在发布时,为了尽快推出,并没有将不同jar包的线程池合并,因为在类加载的过程中会有一些复杂性。

  如今好了,niubi-job已经正式将线程池合并,哪怕你有成千上万个jar包,一个任务集群节点都只会有一个线程池。也就是说,针对上面的情况,假设你将线程池的大小设定为20,那么将有10个任务在运行,另外10个线程等待新的任务加入。如此一来,很显然在极大程度上提升了niubi-job的负载能力。

  是不是很酷呢?

  

0.9.4.2版全新console界面与教程

  

  上面只是针对niubi-job性能上的优化,本次版本还针对console界面做了一些美化,接下来就一起欣赏一下吧。

  

  使用默认的用户名admin和密码123456登录即可。

  登录以后你可以看到下图,这是选择模式的界面。

  niubi-job支持主从和主备模式,两种模式的操作界面是一模一样的,因此我们这里拿主从模式来做例子,选择“master-slave”模式进入下图。

  本人给每个菜单都注明了它的作用,通常情况下,我们的操作顺序是这样的。

  1、上传你的任务jar包。

  2、点击“upload”上传成功后,你会进入如下界面。

  3、这个时候,如果你想对任务进行操作,请点击“schedule”按钮,进入如下界面。

  4、通常情况下,你只需要填写下cron表达式,选择一下jar包版本,点击“execute”按钮,即可启动一个任务。启动以后,你过几秒刷新一下就可以看到以下界面。(友情提醒:如果你的任务状态一直处于“executing”状态,你可以手动点击“synchronize”按钮来手动同步任务状态)

  到此,其实你已经启动了一个任务,如果你想暂停任务,或者更改它的cron表达式并且重启任务,那么只需要继续点击“schedule”按钮进行操作即可。

  

console的一些其它功能

  

  当你启动完任务后,你进入操作日志界面,可以看到如下操作日志。(友情提醒:本文只有一个start操作,其余两个操作是本人私底下操作产生的,不用惊讶哦)

  另外,niubi-job支持多jar包版本,因此当你只上传一个jar包时,所有任务列表是这样的。

  当你再次上传一个1.1版本的jar包时,所有任务的列表是这样的。

  这两个jar包里的任务是一样的,都是Job1和Job2。但是一般情况下,1.1版本你可能对Job1或者Job2做了一些改动。这个时候,在所有任务列表会显示你所有的任务,以任务的唯一标识和jar包名称为联合主键。但是在可操作的任务列表里,会自动按照任务的唯一标识去重,也就是说,不管你上传多少个版本的Job1和Job2,在可操作的任务列表里,永远都只有一个Job1和Job2。

  就像下图这样。

  如果你给一个任务上传了多个版本的jar包,那么在你调度该任务时,你可以选择你的jar包版本。就像下图一样。

  此外,你可以在集群节点列表看到你所有的集群节点,这些节点都是你用niubi-job-cluster包启动的用于执行任务的节点,如下图。

  刚才我们启动了一个任务,因此你会看到集群节点中,有一个任务数已经变成了1,代表它现在运行了一个任务。

  

浅谈下niubi-job未来的规划

  

  现在的niubi-job架构已经基本稳定了,接下来要做的是继续添加功能的支持,目前已经被添加到日程的功能如下。

  1、支持启动任务时给任务方法传递参数。

  2、支持单次运行任务。(现在用cron表达式其实也可以变相达到这一目的,但不够直观)

  3、支持启动任务时指定某一个集群节点运行。

  4、支持给集群节点分组,并且可以给任务添加到某个集群节点分组。(这样做的目的是,如果一个公司有两个或者更多项目组,那么可以给每个项目组分配几个集群节点作为一个分组,每个项目组的任务优先会在自己的集群节点上运行,不会影响其它的。只有当自己分组的集群节点挂完了,才会暂时借用其它分组的集群节点运行任务。当本分组的节点恢复时,再回到自己的集群节点分组上运行)

  5、目前的负载均衡策略是简单的基于任务运行个数。也就是说假设有6个任务,3个节点,那么每个节点会运行2个任务。后期会给任务的每个指标加权,使得负载均衡更加智能化。比如有6个任务,但是可能其余五个任务都是几十秒就跑完了,但是有一个任务得跑10个小时才能跑完,这个时候只基于个数分配就有点不太合适了。我们将记录每个任务的运行时间,以及它占用的资源,来动态的进行负载均衡。

  6、运维指标监控。这些指标包括集群节点和任务的指标。比如每个集群节点的CPU占用,内存占用等等。再比如每个任务每次的运行时间,是否成功等。

  7、给控制台添加更加细粒度的权限控制,和4功能相似,也是为了不同项目组之间的隔离,自己项目组的人只能操作自己项目任务的启动、停止等操作。

  8、其它用户提出的需求。

  

结语

  

  niubi-job不同于本人的其它开源项目,这个项目将会被持续优化下去。因此如果大家遇到了定时任务不好处理的问题,可以尝试使用niubi-job哦。

  最后,希望大家踊跃的提出ISSUE和PR,本人的github地址在博客栏左侧。此外,左侧还有本人的直播地址,在直播中,本人也会解答niubi-job的问题,大家也可以关注一下。

  好了,本文就到此为止了,感谢大家看到最后。

  鞠躬,-_-。


相关文章

暂住......别动,不想说点什么吗?
  • 全部评论(0
    还没有评论,快来抢沙发吧!