可扩展的工作流引擎设计

一. 前言

一提到“流程”，各位看官就山呼海啸——神啊救救我吧：报销流程太慢了、流程五花八门、流程太不智能了等等。“工作流引擎”就是来解决这些问题的！

小生近日应聘，集体面试环节考察设计方面，针对熟悉领域做个方案答辩演讲，于是呕心沥血倒腾出工作流的设计。在这里把思路总结下来，仅仅是个思路，而且重点表达可扩展性。也曾经实现过轻型流程引擎，满足常规需求没这么丰富。小生不才，抛砖引鸡蛋，欢迎猛拍 ^D^

二. 诉求

啥样的工作流引擎，才叫牛叉？请看齐业界大名鼎鼎的JBPM、Activiti、WWF等。我们想象中流程是逐条处理，那只能说想得太美了；现实业务往往要求更高，比如一个主管带2、30号兄弟，一周审批一次工时，就要求单用户一次性批处理上百条流程，还要考虑多用户并发。所以本文更强调高性能、可动态扩展。

对于身边那些剪不断、理还乱的各种流程，比如常见的“招聘流程”，如何让计算机来管理？那就是流程建模！用机器语言表达业务流程。

为了全球范围内规范流程管理，已有多个世界级组织，推行了很多工作流标准。我了解过几个，最熟悉的是BPMN，以下基于BPMN来看如何建立流程模型。建模标准可参考BPMN规范：http://www.omg.org/spec/BPMN/。
1.OMG（Object Management Group）定义的流程标准：BPMN（Business Process Modeling Notation）
2.WfMC（Workflow Management Coalition）定义的流程标准：XPDL（XML - Process Definition Language）
3.OASIS（Organization for the Advancement of Structured Information Standards）定义的流程标准：BPEL（Business Process Execution Language）

三. 功能

要满足上述建模要求，需要哪些功能来支撑？特别是BPMN的要素可谓广而全，囊括了各种千奇百怪的流程，比如活动又分为循环、会签、消息、手工、脚本、规则等等，网关又分为排他、多路、并发、事件、条件等等。

四. 技术

用什么技术来实现上述需求？下图主要表达“核心执行引擎”的实现：
1.工作流中间件主要模块：
流程上下文：好比足球运动中的球，贯彻整个任务过程，负责封装业务数据、流程请求、响应、状态数据；
流程应用程序：好比排兵布阵的教练员，负责调度流程过滤模块和活动处理器；
流程过滤模块：好比传球队员，每次任务由多个模块完成，负责处理事件、网关、连接的逻辑，决定流程走向；
活动处理器等：好比射门队员，每次任务由一个处理器完成，实现任务流转。
2.每个模块均有界面层、应用服务层，基于DDD领域驱动设计思想。
3.为了满足高性能，数据持久层使用内存缓存，底层采用分布式云平台架构。

五. 扩展

重点来了！如何体现可扩展性？
譬如在前文的招聘流程中，用（上）户（帝）要加两条有点变态的需求，一般系统无法满足，只能扩展定制。
1.要求在终面环节，加权会签评审，逻辑如下：
多人参与会签评审，主管位高权重，一票抵三票；
各个评审者对应聘者打分1到100；
最终得分是所有评审者的加权平均分，80以及上视为面试通过。
2.在通知入职环节，原来有给应聘者发邮件，现在要求同时短信通知。

管道模型是神马，怎么扩展以上特殊需求？
谈到扩展性，我们能想到的扩展性很好的框架是啥？没错，就是ASP.NET框架，经典的管道模型兼容各种服务，神马HTML、ASP、WebForm、MVC，甚至图片、PDF、GIS信息等，无所不能！而且可以使用OSGI的思想实现热拔插动态扩展。
在管道模型中，足球（下图圆点）从开球、传球、射门各个环节，都可以被人为干预（扩展定制）；甚至可以拆换动作细节，比如训练时的标准（标准框架）射门动作是停球、抬腿、击球，某场粉丝特别多的比赛中（具体项目），允许略装逼，表演倒挂金钩腾空射门。
1.扩展实现加权会签需求：原来的射手表现一般，只需教练员（流程应用程序）强制将其换下，换上射手王（超强活动处理器）梅西！立即扭转乾坤。
2.扩展实现短信通知需求：在足球传到射手之前，再插个传球队员（短信事件模块），补传一脚把足球更精准地送到射手脚下，必定轻松破门。

六. 数据

流程系统如何存储数据？大概列了一下对象关系，具体实现还要细化。

七. 后语

本文构思参考了BPMN、JBPM、Activiti、微软WWF、ASP.NET框架。要努力爬上巨人的肩膀嘛，哈哈。

本文地址：http://www.cnblogs.com/jakcm/p/PipelineWorkflow.html。

乐于分享，交流进步。