流程引擎与应用系统分布式部署架构

一、为什么应用系统和流程引擎需要分开部署

有句话讲：存在即合理。在实际的企业应用需求里有如下几种场景，需要把业务系统和流程引擎分开部署。

1. 企业流程治理需求。即整个企业只部署一套流程平台BPM，也叫企业级流程中心BPM、或者跨系统端到端流程等，这种架构一般在大企业用的比较多，不单单是技术架构的变化，更重要的是要体现企业级流程治理，以及KPI考核等，这就要求流程模型的一致性，业务系统不能再开发异构的流程引擎了。
2. 应用系统技术异构，但需要工作流。在一个企业里不单单只有一个供应商，或者一个技术体系，往往存在Java、.net、php等多种异构技术的系统，而这些系统常常有调用工作流的需求，如果每个系统都开发一套流程引擎，开发成本和维护成本极高，这时流程引擎独立部署，通过HTTP服务给业务系统提供流程能力是最好的方式。
3. 流程中台架构。当前中台这个概念比较流行，有数据中台、业务中台、技术中台， AI中台、区块链中台、元宇宙中台、AR/VR中台等等。中台实际上一种架构思想，本质上是通过服务方式，提供复用和共享能力，提升前台业务应用的开发和维护效率。
4. 还有统一技术架构，利于技术人员复用，便于日常系统运维，等等。

二、流程引擎和业务系统分开部署的技术难点

业务系统不再含有流程引擎，如果想实现流程审批功能，那么就得依赖独立部署流程引擎的远程服务接口了，目前主流技术是RESTful+JSON格式，本质是是一种HTTP通讯方式，常见的接口有发起流程、流程审批、查询待办等，这些都不是技术难点。比较难处理的是流程权限，在大部分的业务中都有“我的待办”、“我的已办”、“我发起的流程”、“我审批的流程”、“我参与的流程”等这种业务和流程相结合的查询需求，实现这样的需求，就需要关联业务端数据库表和流程引擎数据库表，而这种分开部署架构，数据库是独立的，无法通过SQL做关联查询。注意这种流程权限查询不是单条流程实例查询那么简单，不能通过HTTP服务请求实现，因为数据量太大了。

 

解决方案：

以主流的开源流程引擎jbpm、activiti、flowable、camunda为例说明该解决方案。业务列表与流程表的关联查询，涉及到流程的两张表：“act_hi_procinst”，“act_hi_identitylink”。

1、需要在业务库中也创建这两张表。

2、流程有数据变动的时候，需要同步更新业务库的两张流程表。

3、同步机制借助RabbitMQ消息队列、流程数据同步服务实现。

4、当流程有数据变动的时候，就把数据推送到RabbitMQ消息队列，流程数据同步服务订阅消息，当收到消息后，把数据分发到各个业务库。

详细方案见：https://yunchengxc.yuque.com/staff-kxgs7i/public/fdni4x7ksaxubx7c

三、独立部署的流程引擎应该具备什么能力

IBM对BPM的定义：在业务流程的整个生命周期中对业务流程进行建摸、开发、部署和管理来实现业务策略的it治理过程。

Gartner对BPM的定义：是一个描述一组服务和工具的一般名词，这些服务和工具为显式的流程管理(如流程的分析、定义、执行、监视和管理)提供支持。

参考IBM和Gartner对BPM的定义，BPM平台至少要包含：流程建模、流程引擎、流程监控、流程分析、流程门户等几个核心部分。

1、拖拉拽可视化流程建模

 

2、高效稳定流程执行引擎

3、在线流程监控管理

 

4、多维度流程效能分析

 

5、流程门户统一入口