最近由于公司业务发展需要,要重构一个自己一年前写的服务,好在老版本一直在维护更新,所以绝大部分的逻辑和老版本的架构还是比较清晰的,重构起来难度不是太大。
用了将近4周的时间,终于重构完整个服务模块,重构期间也根据不同的进度做了测试,测试更多的是倾向于接口通不通,整体还算顺利,期间虽然也有bug,但都不是太致命,稍微调整下就能正常运行,等到所有重构工作完成后,大测试开始了。
按照重构后的测试要求,开始最后一个阶段的冲刺,整个重构工作让我痛苦了好几天的地方也正是出现在这个阶段。
首先,一开始测试的时候发现只能达到目标要求的70%,剩下的目标始任务终达不到,花了将近一天时间排查达不到的原因,一开始以为是代码写的有问题,所以又重新梳理了一遍代码,并没有发现什么异常情况。后来经过领导的提示,检测了下程序运行时服务器的各项参数,发现测试到目标要求的70%时,也正是服务器的内存资源不到1G的时候,再单独看每个容器耗费内存的情况,也由刚运行时的100多M涨到了1G多,翻了10倍。
既然知道了造成问题的原因,接下来就是从如何解决内存飚高的角度着手优化了,而这又是痛苦了好几天中最痛苦的点。
接下来,我分别从代码逻辑,调用第三方库时配置的参数,使用不到的方法实现相同的逻辑,增减容器数量,网上搜索相关帖子,请教同事等手段挨个去尝试解决方法,但都无功而返,这两天感觉自己就像是在做某个试验,组合尝试各种可能性。虽然没有找到成功的方法,但是至少知道了很多方法是不起作用的,排除了很多错误选项。而在这一次次的尝试中,最终定位在了rabbitmq接收消息