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的问题，大家也可以关注一下。
好了，本文就到此为止了，感谢大家看到最后。
鞠躬，-_-。