Flowable工作流引擎技术方案

        应对越来越多的工作流使用场景,以及越来越灵活的业务情形,我们亟需对工作流引擎进行一次重构优化。目前市场上主流的工作流引擎,一种是我们熟知的activiti,另外一种就是flowable。众所周知,flowable才是原activiti核心团队这几年的迭代产出物,针对引擎核心代码做了大量优化升级,反观activiti则是将中心放在了云化上,所以,我们本次主要讨论flowable的集成使用。

        2019年初,我们开发了综治平台,该平台时间紧,任务重,为了快速交付上线,我们使用了第三方半开源的项目agileBPM,该项目功能已经很强大了,支持的场景也非常多,当时也顺利完成了交付。但是随着时间的推移,问题也在一点一点的显现。技术老旧,代码繁重,可维护性差,部署复杂冗余,项目集成重复工作多,表单模块实用性差,可定制程度低,各种BUG。这些问题在后续的工作中也着实带来了不小的挑战,虽然在2020年下半年我集中对agilebpm进行了一次架构升级,结合zookeeper做了多应用支持和脚本的发布订阅模式,但是由于项目原因中断,转而去忙公司的项目,也就不了了之。

        如今看来,再多基于第三方固化的东西进行二次开发,特别是技术陈旧且场景固定的项目,不是锦上添花,而是画蛇添足,强行赋予其原本不存在的价值,结果只能适得其反。换言之,我们需要真正结合自己的场景,真正的循序渐进,打造一个听话的,优雅的,轻量级,可持续扩展的工作流”引擎“,而非最开始就做一个平台。随着场景丰富,应用间通用性完善,我们逐步抽取为一个公共能力平台,才是最终可持续发展的重点。

        综上所述,我们早期需要做的是一个多场景可复用的轻量级引擎,以及引擎配套的SDK。

核心思路

工作流一定从引擎开始,它一定是一个渐进式的、根据场景逐步积累的工作。基本思路非常清晰,根据flowable核心架构,我认为最合适的集成方案是:

1. 独立部署引擎,基于SDK + REST API进行交互

flowable项目原生支持多租户、几乎所有的Java API都提供了REST API,我们可以仅实现其适配器,我们的业务系统可以直接通过REST API进行集成,这样即使是早期,也可以共用引擎,无需重复部署

2. 同时拥有独立的UI界面灵活的页面组件

项目早期,我们甚至可以不做任何的UI界面,通过现有的流程设计器,然后仅通过业务逻辑 + REST API即可完成所有功能,实现业务流转。项目中期,我们需要前端同事的参与,开发一套工作流引擎管理页面,负责管理租户、流程定义、流程实例、实例任务以及系统状态。同时,我们的模型设计器、流程设计器也可以封装为一个独立组件,通过NPM包管理灵活嵌入各个业务系统中,集成流程设计功能。后续我们会慢慢加入表单设计器、决策设计器、案例设计器等以支持更加丰富的场景。

3. 灵活解耦,可插拔

本次工作流引擎的建设目标,就是要充分解耦,将该功能真正做到既轻量级、又无比强大,打造成一款强大好用、代码优雅、可持续更新的精品组件。关于解耦的部分,我们可以基于许多中间件进行实现,如基于消息队列完成异步事件的回调,或者基于Zookeeper完成事件的回调,甚至可以用Redis存储回调标识来实现。只要避免相关代码直接耦合交互,这些都是完全没有问题的。

二、怎么集成,如何使用

Flowable官方团队在两周前发布了flowable 6.8.0,该版本着重加强了原生对脚本的支持,增强了事件监听器,将SpringBoot也更新到了我们的基线版本2.7.6,可谓天时地利人和。

集成的主要工作有以下四点:

  1. Flowable核心API适配。下图是flowable的核心api。我们需要将这些api在SDK进行封装适配,内部使用flowable自带的REST API进行代理实现,让使用SDK的业务系统调用起来跟直接使用flowable原生api一样。这部分工作还包含和引擎约定鉴权方式,flowable

Flowable工作流引擎技术方案_第1张图片

  1. 多应用(租户)支持。flowable天生支持多租户,且支持表内字段隔离和Schema级别隔离。通过封装少量配置即可快速支持库表分离。

  2. 用户权限适配。flowable有一套自己的用户体系,但是从v6开始,idm模块便单独剥离出去,IdentityService也充分解耦,流程引擎不再强关联IDM模块。对于我们来说,不需要关注flowable的用户,只需要在流程设计、流程发起时传入用户id即可。我们在实现相关页面时,仅需要调用自己的用户体系接口即可。对于用户权限的控制,由于核心Service入口都在SDK,交由业务系统自己控制,SDK提供默认实现。

  3. 自定义业务回调。在充分解耦的系统中,单向通信是基本原则,但是作为一个成熟的引擎,拥有定制化的能力也是必需的。在许多业务场景下涉及到业务回调,同时还有需要的事件监听需要我们实现。这部分工作将分为两个阶段:

早期:抽取WorkflowScript接口。在引擎端基于数据库实现简单的脚本管理器(租户级别),存取脚本标识符,SDK提供REST代理,在项目启动时注册项目中实现的WorkflowScript,流程引擎调用时使用RMI反向调用。该方案不需要中间件支持。

后期:基于Zookeeper管理脚本节点,引擎端监听并实时更新脚本映射,用户任务触发脚本调用回调到业务系统。该方案需要使用ZK作为注册中心,增加了部署难度,调试难度,建议等基本功能稳定了再进行开发。

SDK提供的需要实现的接口:

  1. WorkflowIdentityProvider必须实现。作为标准的用户访问api,为了保证代码结构稳定,流程设计器调用接口稳定,需要业务系统自行实现相关逻辑,包括用户列表,用户详情,用户权限列表,用户权限过滤,部门列表,部门权限等。

  2. WorkflowScript。可选实现。注册到引擎的脚本,可以在流程设计器中的脚本编辑器使用,可回调到业务系统执行相关逻辑。

  3. WorkflowListener。可选实现。可以动态监听所有流程实例和任务流转的每个状态,早期不实现,需要结合zookeeper实现。

集成后业务系统如何使用呢?

  1. 引入SDK,并添加workflow.yml配置文件,配置引擎地址,应用标识等基本信息。

  2. 用户权限控制模块实现。需要结合自身的用户体系来实现该WorkflowIdentityProvider

  3. 引入流程设计器和流程图渲染器,在需要的页面嵌入流程设计器,在查看流程进度时展示流程图进行状况。

  4. 根据实际业务调用流程发起接口,在涉及到流转的页面调用流程流转接口。

三、实现模式一览

Flowable工作流引擎技术方案_第2张图片 

 

你可能感兴趣的:(设计,java,运维,设计模式,spring,boot)