基於任務的系統架構

    任務是指實現單一功能的單元。對於"單一功能"的認定沒有通用標準，單元的顆粒可大可小；能夠是一個算法的實現、一個公共方法或者一個事務等。

    通常的系統採用基於任務的架構，主要針對兩個問題：1，併發執行的須要；2，定時執行；對於以上兩種場景的分析這裏再也不贅述。我從解耦的角度再深挖一下這種架構模式的優勢和適用場景。提到解耦，經歷過度布式系統設計、開發的同仁都有體會；它是系統容量、性能、可擴展性、可維護性提高的重要基礎。實現解耦的主要途徑是分佈式系統間的接口調用、引入消息中間件、利用DB持久化等方式；這是較大顆粒度的解耦，因爲接口調用、消息、持久化等方式都是物理層面的解耦，因此從軟件實現看：解耦地生硬。

    我想更加精細的解耦-採起任務模式的系統架構，將任務間數據的傳遞採用分佈式系統間接口調用、消息、持久化等；而任務間數據的傳遞經過任務執行引擎對任務屏蔽。同步方法調用以下圖左側所示，（分佈式系統間的同步）接口調用也於此相似；過渡到任務模式的系統架構時，調用關係發生了變化：方法間再也不直接調用，而經過任務執行引擎（配合事件或者工做流）組裝了方法調用；任務的運行時能夠利用多線程得到更好的執行效率，也能夠利用執行引擎得到對稀缺資源的軟同步控制。

    基於任務的系統架構更容易實現分佈式橫向擴展，與面向接口相比，它是面向（任務執行所需的）數據的，不存在接口變更的重構問題，且將數據處理算法封裝在一個獨立執行的單元中。任務的執行有兩種策略：1，由前一個任務執行完後，啓動下一個任務；2，由守護線程根據經過狀態機建立執行任務；這兩種方案我比較傾向後者；本質上差很少，可是後者對於測試有更好的效果。

    基於任務的系統在TDD、BDD、DDD都有比較好的使用效果；通常意義的TDD是面向API或者接口的，這裏的TDD是面向任務的，明確了每一個任務執行以前、執行以後數據的狀態機；從而爲業務級別的複用奠基了基礎；在BDD的實踐中，任務模式也能夠得到很好的測試效果，由於BDD就是經過比對數據的值校驗測試結果的。以上兩類測試中，都不用啓動任務引擎，經過任務間的方法調用，就能夠實現測試過程。DDD是從業務級別的封裝，也就是大粒度的任務或者任務組合。

    有利就有弊，與單一應用相比，這樣的系統架構比較複雜；與（接口調用式的）分佈式系統相比，這樣的系統架構也沒法利用語言的靜態檢查。比任務架構更復雜的是基於事件的Actor架構，後者更加精緻，併發性能更好。

    該系統架構的關鍵在於控制任務的顆粒度。