在日常開發中除了給前端開發接口，還要寫一些定時處理任務，比如一個活動需要每天定時給所有用戶派發獎勵。一個成熟服務框架需要一個全局的定時任務調度中心，通過定時任務調度中心可以查看服務有哪些定時任務以及定時任務的執行情況，對於執行失敗的定時任務可以手動執行等。
我們公司的微服務架構沒有定時任務調度中心，每個服務通過類似crontab定時任務配置來管理自身的定時任務，爲了保證每個服務高可用，我們給每個服務都部署了兩個節點，對於一些不能併發執行的定時任務我們往往需要給定時任務加一個分佈式鎖，有時甚至需要修改服務的crontab定時任務配置，保證一組服務只一個服務能執行定時任務，對於定時任務執行情況沒有一個統一地方可以查看，需要查看每個服務日誌才能確認定時任務是否執行成功，對於執行失敗的定時任務需要寫額外的重做代碼。所以我們需要一個定時任務調度中心來管理每個服務的定時任務，這個定時任務調度中心需要有以下功能：
- 可以查看服務有哪些定時任務以及任務的執行狀態。
- 對於執行失敗的定時任務可以在管理界面手動發起重做。
- 每個定時任務都抽象成接口，由定時任務調度中心負責調度。
- 定時任務什麼時候執行應由具體業務服務配置，定時任務調度中心可獲取這些配置進行定時調度。
既然決定開發一個定時任務調度中心，那麼問題來了，我們是否需要開發一個新的服務？我的答案是不需要，我們把定時任務當作服務接口，我們所有服務的接口信息都登記到服務註冊中心，我們可以給接口添加一個定時任務標籤，註冊中心將打上定時任務標籤的服務接口放到一個定時任務執行隊列中，由定時任務執行隊列管理每個服務定時任務接口的調度，同時將各個服務的定時任務接口與執行情況記錄到數據庫中，然後在註冊中心添加一個定時任務管理頁面來管理各個服務的定時任務。
定時任務調度中心的大致思路有了，剩下的過程就是將實現思路具體化。我們現有的定時任務配置與crontab類似，可以按分鐘、小時、日期、月份、星期等幾個維度進行配置，如果定時任務調度中心全部實現這幾個維度的配置，會導致定時任務配置解析與調度邏輯變得複雜，一個框架因爲簡單才更加穩定可靠，我決定對定時任務配置維度進行簡化處理，最終抽象出以下兩類定時任務：
- 每隔N秒執行一次的定時任務。
- 每天特定時間點執行的定時任務。
每個定時任務都可能執行多次，即每個定時任務可以有多條執行記錄，所以可以在定時任務管理頁面中查看每個定時任務的執行情況，但日常運維中我們不是很關心定時任務的歷史執行情況，如果記錄定時任務每次的執行情況，我們還要考慮如何管理歷史執行記錄以及歷史執行記錄太多了該如何處理，我不希望因爲開發定時任務調度中心導致服務註冊中心過於臃腫（定時任務調度中心當作服務註冊中心的一個子模塊來開發），所以我決定我們的定時任務調度中心只記錄每個定時任務最近一次的執行記錄。
對於日常運營活動中的定時任務，在活動結束時這些定時任務的生命週期也結束，這就要求業務服務的定時任務可以自動卸載，我們約定當定時任務生命週期結束時業務服務的定時任務接口應該返回UNINSTALL錯誤碼，任務調度中心調用定時任務接口時如果接口返回UNINSTALL錯誤碼則將定時任務從任務調用隊列中移除。
根據以上的思路，我們開發了一個足夠簡單穩定的定時任務調度中心。首先我們針對兩種類型的定時任務添加以下兩個註解，接口類的註解信息最終會上報的服務註冊中心。
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public static @interface TimerTask{
int value(); //每隔N秒執行一次(值爲整形)
}
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public static @interface DailyTask{
String value(); //每天特點時間點執行(如：09:00:00)
}
我們希望添加一個名爲SendPrize的定時任務，這個任務每天09:00:00執行一次，則我們只用給這個類添加DailyTask註解就可以了，相關代碼如下：
@DailyTask("09:00:00")
@WebAppPath("${classname}")
public class SendPrize extends WebApp{
public void process(HttpRequest request, HttpResponse response) throws Exception{
response.setBody("hello world");
}
}
