鏈家分佈式做業平臺

背景

隨着貝殼的業務功能的不斷擴大，具備複雜功能的單體應用隨之進入了微服務開發的迭代模式。項目須要做業調度模塊是個常見需求，在以前單體系統中，集成了quartz完成做業調度模塊，由於單體應用集成一次後，單從技術層面看幾乎沒有新的工做量，並且總體仍是比較穩定的，可是當單體應用進行微服務拆分後，不少微服務項目都須要集成做業調度模塊，常規的一些做業調度實現，已經沒法知足公司級的微服務項目拓張，一種輕量級、分佈式、統一管理的做業調度框架勢在必行。

需求

• 從公司角度的需求：因爲單體應用改成微服務項目，微服務項目的做業調度功能百花齊放，做業調度系統在總體項目體系中屬於底層基礎組件項目，總體需易於接入公司的監控和規範，原理需徹底掌握，如任務執行出現問題，要有及時的報警以便及時跟進，定時日報，彙總總體微服務系統做業調度狀況。做業調度原理要100%的掌握，不容許線上出現技術原理不清而阻塞故障的修復。當接入做業愈來愈多時，要有負載機制，監控總體系統運行狀態。
• 從業務系統角度的需求：做業調度系統要很是易於接入，且接入問題須要有專項小組提供解決方案，不能阻塞業務系統開發，做業須要靈活配置，且調度要準確。並且用戶手冊要足夠強大，做業調度專項小組在必要的狀況下要持續支援有些快速開發的業務項目，由於這種突擊項目着重關心業務實現，根本不關心基礎組件實現細節，更不想遇到組件使用的阻塞。即：投入低，回報高。

技術調研

• 在github上調研了目前比較流行做業調度項目，其大體能夠分爲一下幾個形態：
• 1 深度優化定製Quartz形態：深度瞭解學習改造Quartz源碼，將Quartz使用DB遷移至使用zk，經過開發後端管理系統操做zk，從而來管理整個做業調度任務的配置，這種形態的做業調度，原理上做業調度實現仍是在客戶端完成，管理系統很弱化。這樣的做業調度系統有個與生俱來的優點是：在管理系統出現故障時候也不會影響做業的繼續做業。由於客戶端項目幾乎集成全量的做業調度代碼實現。

• 2 Quartz服務端形態：將Quartz抽象並封裝成服務端，客戶端經過基礎client-refence.jar完成任務的勾子方法暴露，服務端完成做業配置任務，看成業有任務觸發時，經過一種協議觸發客戶端項目任務的勾子方法，完成調度。這種形態的做業調度框架，客戶端必定程度減小了做業調度代碼量，和項目性能消耗，可是帶來了不少分佈式調度問題，須要深刻了解總體調度的實現。

• 3 自實現調度系統，這種形態的做業調度系統基本都是功能很是多的，功能自實現一部分，也可經過SPI集成一部分，好比調度能夠用Quartz實現，可有自身項目經過解析語法如：CronExpression.java實現Cron做業解析出將來必定時間內的任務，當時間到達觸發時間。觸發可支持客戶端集成，或經過一種協議觸發客戶端項目任務，完成調度。學習這類形態的做業調度架構，能夠發人深省，不管從廣度或者深度，均可以使學習者對做業調度架構的認識更上一層樓。

思考與實踐

經過對做業系統的背景需求的認識，和在github進行的技術調研學習，結合咱們自身特色，在實現本身的做業調度過程當中，咱們思考了以下幾點，

• 調度設計與實現：客戶端暴露任務，經過註冊發現將任務與服務端數據同步，在服務端將發現到的任務自定義的組裝成做業，完成總體做業調度功能。服務端集成公司監控和規範。
  • 總體架構設計

    

  • 做業調度原理實現

    

• 做業調度服務端高可用的實現方案：服務端經過zk主備選舉，完成服務端自身高可用實現，另外服務端暴露出健康接口，這裏咱們公司有對服務健康接口的持續監測，若是集羣中，某個健康接口出現異常，會馬上報警給值班人員。
• 做業調度服務端實現：這裏咱們參考了大量技術調研第三種形態中功能實現，經過對調度底層實現方式的學習，實現任務在服務端可配置做業。
• 如何作到客戶端極簡實現：做業調度需求項目經過集成client-refence.jar將任務方法暴露到註冊中心，並內部實現任務觸發方法，以便完成任務調度的觸發。這裏咱們經過反射機制，經過在方法上增長特定註解，識別出此註解方法爲任務方法。
• 任務方法的註冊發現：前面說了客戶端的極簡實現，任務的註冊發現咱們經過將識別出的任務方法，放到註冊中心上面，且經過心跳完成本地暴露任務與註冊中心的任務持續的一致性。
• 項目權限設計：隨之客戶端項目愈來愈多的接入做業平臺，確定是須要一種權限體系完成客戶端接入項目的邏輯隔離，這裏咱們參考git項目人員管理體系，項目名稱爲惟一標識，建立項目的同窗爲此項目的owner，可根據系統號邀請其餘同窗加入此項目，共同維護此項目做業配置。
• 異常報警實現：定義異常事件類型，和內容，如：任務失敗事件，內容是異常信息等，經過觀察者模式結合項目人員完成異常事件的實時報警。結合上面的權限成員，馬上發送給任務所在項目組成員。
• 依賴、分片任務的實現：這裏咱們參考了一些國外的科研項目，結合業內比較流行的設計，經過用有序無環圖（DAG）來實現任務的串聯依賴，與任務的平級分片。

總結

在深刻學習做業調度框架的過程當中，基本上全部框架解析Cron做業都是經過org.quartz.CronExpression.java實現解析的，以後經過解析出的觸發點，完成觸發。做業調度系統在總體項目中屬於很底層的基礎服務組件，很現實的問題是：不少業務項目其實對底層項目實現根本不關心，只要學習成本低，高可用，有專項小組維護，因此在作項目的設計實現的時候，要着重考慮用戶的核心訴求。做業調度系統在生成中每秒鐘中須要推送的任務不多，核心訴求並不是高併發，因此咱們設計的系統指標定義是秒級任務量的觸發延時指標，還有是底層系統必定要大而全，且學習成本低，提供一套默認的推薦配置，也要有高級知足各個業務線常規的自定義配置，