工作小记1

目录

就上次的问题消息系统顺序问题,考虑到修改消息系统模块风险大,太多其他模块使用了该模块(由于系统技术债务,系统并没提供扩展写法,对该模块也没有足够的单元测试),最后没有就该思路走下去。
原来的业务问题是APP端有两次请求(一先一后),后台要求有顺序,否则可能执行不成功。至于为什么原系统是这样我就不知道了…两次请求会执行一些简单的逻辑,然后第二次请求会通过消息系统调用后面的服务,此时若第一次请求没有执行完,后面的服务就报错。
最后采取的方案是将操作2(包含参数)存入数据库,然后写定时任务再去调用,从而保证操作2在后面执行。
解决方案不优雅,但也算能解决当前的业务问题。重构好像要提上进程,希望能还些债务。