工做流與任務

    基於工做流的系統架構是一種常見的通用的系統架構。經過工做流步驟的組合知足業務流程的配置和變更。每一個步驟之間要麼是共享數據，要麼是傳遞參數，來支持工做流引擎實現步驟間的調用；所以下一步是知道上一步處理結果，不管是下一步的參數初始化仍是下一步讀取共享數據。

    基於任務的系統架構是與基於工做流相似的系統架構；任務分爲定時任務、(條件觸發)一次性任務（鏈）、（ForkAndJoin的）複合任務等。任務從形態上比較相似工做流的步驟，經過共享數據，基於狀態機實現業務邏輯。與工做流相比，任務的組合更加靈活，由於任務之間是沒有關係的--即便複合任務，也不過是爲了方便任務的管理，徹底能夠將其分解爲獨立的任務，利用獨立的狀態機實現其業務邏輯。

    獨立的任務集帶來了更好的併發性，再也不遵循業務請求個數與執行線程數至關的慣例；例如這樣的業務場景：在處理業務邏輯的事務結束後，須要短信通知用戶；並將處理結果同步到客服系統。工做流模式大約須要三個步驟完成；而任務模式的一種實現是建立三個任務，短信通知任務、同步數據任務能夠併發執行；另外一種方案是在處理業務邏輯的任務結束時，建立另外兩個任務便可。併發不止用於這些過後通知、同步的實現，還能夠用於業務數據的準備、可併發的數據操做等。

    任務的顆粒可大可小，從系統架構層面看，一個子系統能夠是一個任務，它從運行以後，就按照while(true){}的模式在運行；遇到知足條件的數據就進行處理，不然就休眠；這個層面相似工做流的步驟，只是沒有系統真的會這麼實現。劃分任務顆粒的大小是重要設計目標，以封裝、併發爲出發點。一個業務對象的處理封裝在一個任務鏈中。與其餘業務對象的交互經過建立新任務、事件、消息等方式觸發。這裏所指的業務對象不是單一的數據或者數據集合，而是承載一項業務的數據集合。工做流的步驟更可能是基於邏輯封裝、複用的考慮劃分的；它更注重事務、異構系統、代碼複用。

    有利有弊，基於任務的系統架構必須有清晰的狀態機驅動，但狀態機隱藏在代碼實現中；工做流模式隱含了狀態機在步驟間的跳轉中，但能夠經過BPMN轉化的圖形UI清楚看到狀態機。雖然二者能夠進行混搭，必然以工做流爲主導，造成了無入參的步驟。我以爲這樣不可取，根據主要目標選擇合適的架構，是系統架構師的責任，混搭不是不能夠，關鍵看：是有清晰的目標，進行有機的融合，產生積極有效的做用。

    最後說說這兩種模式在測試方面的差別：以工做流爲核心的系統，若是其步驟間的分界很是清晰，則很難對步驟進行單元測試，即，要求步驟是面向接口開發；以任務爲單元的測試則相對清晰不少，由於開始時就標定了清晰的狀態機和執行條件。當進行集成測試時，二者不相伯仲，測試難度都略大。