工作流组件性能问题定位------来自内部的争吵

经过2020年以来的产品转向，已在多家公司上线，就是在这几年中，统一流程平台的概念在集团企业已慢慢应用。所以，在推广过程中流程不再是我们的核心，能应付就行（这是我们实施的真实反馈）。但以企业内部审批流转为核心的系统，合同与法务管理平台对工作流的要求较高，一般的流程平台无法满足。

我们再转向过程中，引入了flowable6.5平台作为工作流的基础组件，并对它进行了全面重构，或者说对它进行了全面的改写。怎么说呢？flowable体系采用了统一的架构来规范代码，采用了数据库大事务来保障事项的完整性，但对于中国式的流程中，存在大量的违法flowable规范的事项存在：如事项审批与流转分离。在大多数审批规划中，流转都能自动完成。但确实存在无法自动流转的情况，这时中国式的流程中需要进行事务断联，并由发起人完成手动流转；在流程审批中存在大量审批驳回，flowable本身不存在驳回的概念；驳回后的提交策略有多种可能，flowable未提供相应的解决方案。审批执行者的概念被我们重新定义，并构建了体系化的执行者解析方案等。

当我们对flowable或者说工作流体系的原理有一定的了解后，发现flowable是不可能快的组件，它优先需要保障的是事项的准确性，在这基础之上才有性能的需求......

所以，在管理软件中，会集成大量的性能无法太快的服务组件：如OCR识别服务/工作流运行服务等。怎么来规避慢组件对整个体系的影响呢?真的就只能由开发人员来解决吗？

在计算机架构中，执行速度大体是【CPU > 内存 > 硬盘】。为了解决这个问题，在各个层级中构建了缓存区，让各层间能有一执行缓冲，最终实现相对平衡。

基于性能需要，在产品构建之初就完成了业务库与工作流库的独立。尽可能的规避事务的影响。在推广硬件资源配置中，需要根据业主单位的业务性质，提出硬件资源要求。

工作流涉及的面广，运维难度高，但使用相应的资源提供符合企业需求的响应速度是没问题的。性能的优化，将不断严控运行数据量，让高频操作的数据控制在必须范围内，及时清理垃圾数据。是工作流性能优化的主要方向，而不是为了快而快，要在保证数据准确性与完整性的基础上进行优化。同时需要把性能问题分开考虑，从硬件资源/产品架构/业务要求等多方面综合优化，实现最终的性能需求，而不是只早开发优化代码.........把问题全推给开发...