进入第4个运行年度,业务数据量沉积给产品带来了性能问题。为提高软件的可用性。对工作流组件进行了全面构建。构建过程分为几步进行:缓存优化/消息组件独立/运行数据分区【运行库/业务库/业务沉积库】。
缓存优化:在为规划独立缓存服务前,对变更频率较低数据基础数据进行了较长时间的内存缓存[30分钟];对更新较为频繁的数据采用来了短频缓存机制[只满足request请求级别]。改善后,数据库的直接访问次数大大降低。
消息组件独立:工作流引擎核心表不再为消息显示提供数据源,引入独立的工作流消息套表,使工作流核心表为消息组件提供一次性构建数据源。构建后消息将独立提供读服务。消息不再直接依赖核心表,工作流监测服务对消息的延后重构提供了可行方案,使工作流引擎进入可自我修复阶段。
运行数据分区:在数据量小的时候,工作流所有数据都在核心表中,简单了工作流构建方案。随着时间的数据沉积与业务全面推广,并发量与数据量的双层压力,使工作流引擎无法有效提供及时服务。经过对数据统计,在几个大集团的数据量中,总数据量在100w。运行中的业务量在5w,及审批记录量在20w左右,按照这个数据积累进程,年度沉积量将进入50w。为在不增加硬件前提下提供平稳的响应体检,对数据进行读写分离改造,及为执行中数据提供运行库【5w-30w】数据量,业务库【存储近N年的完成业务】,业务沉积库【存储N年前的完成数据】。
flowable采用了类似的方法,但本次改造在它的基础上进一步引入业务沉积库概念。将提供更为长时间的高可用性方案。