2019，缓慢前行，基本完成工作流引擎改造，全面引入rabbitMQ消息组件，为数据库IO消峰带来一定的帮助；引入基于时序的监测任务，为工作流引擎打通数据自我修复机制；引入独立的工作流消息体系，为管理系统内置任务办理提供小数据量查询方案；引入运行库概念，使高频使用数据独立，提升工作流引擎状态判定响应，并降低因高频IO操作对数据库的压力；引入沉积库概念，为低频使用数据提供独立存储......
经过改造，经过4年构建,改造的工作流引擎基本达稳定运行阶段。在这4年里，经历过流程运行异常的揪心，经历过不断膨胀的业务接入压力，经历过为适用客户企业发展而进行的次次次更新。经过不断的调整/优化/重构，产品变得更为稳健/高效，适用能力不断延伸，只是代码中不断在增加记录着我的签名，在每一个改造点，留下了自己印记......
4年里【工作流】成为不被欢迎的代名词，公司80%的运维量来自于流程流转支持.....................心疼运维同学们.
年初很是纠结，工作流到底要怎么发展，才能降低运维量，怎么才能适应客户快速增长的业务带来的性能压力？很多时候让我们不得不想这些问题。如果不考虑，产品将无法适应企业的需求，自然也就废弃。只有我们遇到这样的问题吗？客户换一套产品就能解决吗？基于与客户的交流，很多系统都有这样的问题，那我们能怎么去解决这个问题呢？
3月到5月，在贵阳一直在想这些问题----------缓慢与纠结。客户年度升级的时间是确定的。在无大动作的上半年，有时间让我们思考问题之外的问题。性能/健壮性，跟我们写的代码有很大的关系，跟网络环境、业务数据沉积也有很大的关系，很多时候是积累效应带来不可逾越的问题。
这段时间心累,纠结，在纠结中不断找资料充实自己，关注Quartz3.08版本的引入是在这几个月对整个源码反复研究后作出的决定，对调度的整体思维方式进行了一次提升。在2016年为拆分业务执行段时，构建一个基于timer的简单时序调度任务。而Quartz解决了调度与作业分离的问题，执行时机的多样定义，并对执行时机可控设计是我们缺失的，所以对业务标准化改造后Quartz成为工作流时调度器的优等选择。
同样对MongoDB,redis等相关开源封装进行了研究。补足对Nosql的恐惧心理，因为他们存在有点的同时也可能会带来”灾难“，所以产品重构时要谨慎引入，可控范围内使用。
解决性能的问题不依赖神话，改造的方向还是数据模型构建，让数据库慢慢回归到存储数据的本质。拆表/拆库是保证系统长期高效/稳定运行的基石。
在5到6月提供了当前被定义为业务沉积库的方案，并完成了产品改造，让查询数据与高频使用数据基本分离。但前端产品需要改造，给客户升级改造带来不确定性？整体讨论时未通过，但整体方向是没有问题的，只是怎么控制风险的问题。运行库与业务库方案被搁置。
面对不断扩大的业务数据规模，我们必须面对，在参照flowable方案后，重新定义运行库/业务库/业务沉积库方案。经过一个月的努力，在发布第一个运行库方案后，团队测试出100多个优化点，经过一个星期的改进，今天基本确认发行基础版本。经过测试改造后，将在近期应用到生产环境上。
有点遗憾的是，我的团队只剩下我了【开个玩笑】,其实整个年都这样~~~~~~~~~~~~~~~我需要一个助手帮我应对基本问题。 不过也无所谓了，可以在北京找合适的人进行分解,所以我的团队延伸了...........
我只是一个从规划/设计/开发/定型的程序员，不对，这5年应该叫 构建工作流的程序员，一个覆盖军工、制造、能源、环保、高校、港口等行业合同管理与法律事务管理的工作流程序员。
下一个5年，值得期待.............