工作流与任务

    基于工作流的系统架构是一种常见的通用的系统架构。通过工作流步骤的组合满足业务流程的配置和变动。每个步骤之间要么是共享数据,要么是传递参数,来支持工作流引擎实现步骤间的调用;因此下一步是知道上一步处理结果,不论是下一步的参数初始化还是下一步读取共享数据。

    基于任务的系统架构是与基于工作流类似的系统架构;任务分为定时任务、(条件触发)一次性任务(链)、(ForkAndJoin的)复合任务等。任务从形态上比较类似工作流的步骤,通过共享数据,基于状态机实现业务逻辑。与工作流相比,任务的组合更加灵活,因为任务之间是没有关系的--即使复合任务,也不过是为了方便任务的管理,完全可以将其分解为独立的任务,利用独立的状态机实现其业务逻辑。

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

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

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

    最后说说这两种模式在测试方面的差异:以工作流为核心的系统,如果其步骤间的分界非常清晰,则很难对步骤进行单元测试,即,要求步骤是面向接口开发;以任务为单元的测试则相对清晰很多,因为开始时就标定了清晰的状态机和执行条件。当进行集成测试时,两者不相伯仲,测试难度都略大。


你可能感兴趣的:(并发,工作流,任务,步骤)