● 流程模块开发与设计：在项目前期，我主导了需求调研工作，基于调研结果完成了流程模块的架构设计。通过与前端团队的紧密协作，实现了流程与节点的可视化配置功能，包括控件信息校验、节点查找策略等核心模块的开发。在技术实现上，我运用SOLID设计原则，结合设计模式，确保了系统的高内聚低耦合特性，为后续功能扩展提供了良好的架构基础。最终成功交付了可灵活配置的自定义工作流交互系统，满足了业务场景的动态需求。 ● 流程版本升级：主导从1.0到2.0版本的升级，将流程图方式转为拖拉拽界面。分析数据结构差异，设计算法完成数据迁移并适配，避免业务人员重新搭建，并保障原有功能正常运行。 ● 定时任务模块开发：将Spring定时框架升级为Quartz框架，处理多种业务场景（如定时触发、日期字段触发、定期清理），提高任务调度的灵活性和稳定性 ● 流程引擎核心组件开发 ○ 使用Nashorn JS引擎执行后端JS代码，实现代码块节点的支持，目前支持ES5语法，未来可扩展至ES6 ○ 利用Kafka消息中间件处理表单变动触发流程，解决消息丢失和幂等性问题，增加后置拦截，实现对多场景的控制 ○ 针对流程中复杂的自定义场景，我主要完成了多个节点功能的开发（如新增、更新、删除、查询、API请求、代码块、函数、JSON解析、人员信息获取） ○ 针对流程中复杂的数据控件解析需求，我设计了通用的字段解析方案。主要通过搭建流程图可视化各类场景，采取多个策略模式进行解析。 ● 数据分表：针对运行时实例表数据量过大导致的性能瓶颈，我设计并实施了分表优化方案，同时确保了对历史数据的兼容性。主要通过设计日期分区策略，按年月维度进行数据分片，同时建立冗余表（记录查询字段并对高频查询字段建立索引），通过冗余表多线程反查分片表，最后编写同步脚本兼容历史数据 ● 性能优化： ○ 背景：流程中单个执行，小数据执行没什么问题，但业务人员统计数据时跑大量流程，接近30-40万实例，执行非常耗时（一分钟600-800条）且服务可能跑崩其他服务（这块主要是限流），由于内存足够则使用的G1垃圾回收器，默认配置4G堆内存，元空间128M ○ 解决过程： ■ 从JVM层面出发：服务器跑业务时通过jstat观察各项性能指标，GC次数,GC暂停时间，发现FGC频繁，暂停时间长，发现堆内存使用正常但查看日志发现元空间内存溢出，调整原来的元空间大小由128M到512M。调整后youngGC频繁，FGC次数一次，由于现场资源足够将堆内存由4G提高至8G。调整后GC运行正常但执行还是较慢 ■ 故从数据层入手：查看连接数，发现连接数多且耗时，故分析耗时连接建立相关索引，但对大表数据后续可分表处理，定期清理。最终实现并发一分钟1800-2000 ■ 应用层面：主要通过监控代码耗时检查不合理代码（for循环查询）