IT工程師數位筆記本

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的問題，大家也可以關注一下。

　　好了，本文就到此為止了，感謝大家看到最后。

　　鞠躬，-_-。