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

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

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

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、流程门户统一入口