2019，xx集团合同管理系统升级

来芜湖一周了，这一周过得充实，紧张，有序，协同...... 带着2019年里工作成果，用于支撑业务模型的变化。公司的集团版工作流经历四年的发展，来到的第4个版本，企业内部代码为R11版本。

这一年，业务审批数据量进入百万级。由于产品设计的历史原因，基于视图的业务数据构建方案把查询数据量达到了10亿级别。使业务数据查询性能非常低。作为合同管理系统在业务中高频使用的工作流组件，在性能体验上尤为突出。

为了解决性能问题，年初提出待办消息独立，运行库与沉积库独立的思路。使高频使用的工作流消息模型回归到实体对象模型，并且作为审批过程中业务数据截取留存机制，使待办消息成为独立体系。引入消息机制，把工作流引擎回归流转核心，消息组件拆分出待办业务构建,消息体系构建，消息补偿机制构建等部分。

经过半年的投入，rabbitMQ消息组件作为中转站，连接了工作流引擎，工作流消息组件，第三方消息集成等部分。

长沙研发中心在有限的资源下，完成了消息组件引入，并深化应用。pc工作流前端完善，移动应用工作流完善，工作流消息组件完善，以及window服务统一标准组件，接口平台发布标准组件等。资源多吗？累吗？干得多获取的不一定多。

4年前的今天，也是在芜湖，刚从广州回来的我正在准备工作流引擎重构，4年后的今天，也是在芜湖，亲自主导版本的升级。

想起2016年1月底，在广州升级的日子，自己带着开发的第一个版本去升级，成功或失败，将决定者多人的去留----自己就是全部支持，现场只有一个发布版本，没有源码，心情只能用呵呵代替。

四年后的今天，在完成芜湖项目升级后，记录下这时的心情。4年的成果是什么？是不断降低的运维成本？是不断完善的基础框架？还是不断从容的升级经历？用4年的打造的工作流引擎，在不断的服务着企业业务？

 

这一路走来的四年，已完成10几家集团公司推广。工作流引擎一直在升级，在更新，在根据业务模型不断扩展.......性能挑战在后续的版本中不在是问题。

业务变化是永恒的话题。

2019-08-31 在芜湖