工做流与任务

    基于工做流的系统架构是一种常见的通用的系统架构。经过工做流步骤的组合知足业务流程的配置和变更。每一个步骤之间要么是共享数据，要么是传递参数，来支持工做流引擎实现步骤间的调用；所以下一步是知道上一步处理结果，不管是下一步的参数初始化仍是下一步读取共享数据。

    基于任务的系统架构是与基于工做流相似的系统架构；任务分为定时任务、(条件触发)一次性任务（链）、（ForkAndJoin的）复合任务等。任务从形态上比较相似工做流的步骤，经过共享数据，基于状态机实现业务逻辑。与工做流相比，任务的组合更加灵活，由于任务之间是没有关系的--即便复合任务，也不过是为了方便任务的管理，彻底能够将其分解为独立的任务，利用独立的状态机实现其业务逻辑。

    独立的任务集带来了更好的并发性，再也不遵循业务请求个数与执行线程数至关的惯例；例如这样的业务场景：在处理业务逻辑的事务结束后，须要短信通知用户；并将处理结果同步到客服系统。工做流模式大约须要三个步骤完成；而任务模式的一种实现是建立三个任务，短信通知任务、同步数据任务能够并发执行；另外一种方案是在处理业务逻辑的任务结束时，建立另外两个任务便可。并发不止用于这些过后通知、同步的实现，还能够用于业务数据的准备、可并发的数据操做等。

    任务的颗粒可大可小，从系统架构层面看，一个子系统能够是一个任务，它从运行以后，就按照while(true){}的模式在运行；遇到知足条件的数据就进行处理，不然就休眠；这个层面相似工做流的步骤，只是没有系统真的会这么实现。划分任务颗粒的大小是重要设计目标，以封装、并发为出发点。一个业务对象的处理封装在一个任务链中。与其余业务对象的交互经过建立新任务、事件、消息等方式触发。这里所指的业务对象不是单一的数据或者数据集合，而是承载一项业务的数据集合。工做流的步骤更可能是基于逻辑封装、复用的考虑划分的；它更注重事务、异构系统、代码复用。

    有利有弊，基于任务的系统架构必须有清晰的状态机驱动，但状态机隐藏在代码实现中；工做流模式隐含了状态机在步骤间的跳转中，但能够经过BPMN转化的图形UI清楚看到状态机。虽然二者能够进行混搭，必然以工做流为主导，造成了无入参的步骤。我以为这样不可取，根据主要目标选择合适的架构，是系统架构师的责任，混搭不是不能够，关键看：是有清晰的目标，进行有机的融合，产生积极有效的做用。

    最后说说这两种模式在测试方面的差别：以工做流为核心的系统，若是其步骤间的分界很是清晰，则很难对步骤进行单元测试，即，要求步骤是面向接口开发；以任务为单元的测试则相对清晰不少，由于开始时就标定了清晰的状态机和执行条件。当进行集成测试时，二者不相伯仲，测试难度都略大。