##前言
第三周,只上了三天班,请了星期四星期五两天凑周末去了毕业游,哈哈。
虽然这周只上了三天班,但过得并不轻松,主要是心累。因为得确保改进的功能没有问题。
上周开始就在改进项目的日志功能,之前系统的日志功能做得好差,不该记录的日志记录了很多,该记录的日志记录了但是却缺少连接,无法定位上下文。日志功能是主要要改进的地方。另外,齐说要增加一个钉钉通知功能,对于指定类型的错误,要通过钉钉机器人API接口,将错误信息在钉钉群里通报提醒。(目的是什么呢?目的就是我们主要去发现问题并解决问题,而不是等有用户向客服投诉了我们才去处理这样的问题)
这两个功能在上周六日总算是弄完了,在这周一的时候开始测试。为什么说是测试呢,因为该项目没有测试环境可以测试,因此我只能在我的毕设项目上模拟测试,测试钉钉通知机器人API接口是否能生效。
##第一次推上线
第一次把新版本推上线是在周一上午七点多,那是我第一次把项目推上线,很紧张。推上线之前确认了一遍流程:
- 把新的war包放到webapps下
- 将旧的war包改后缀,使之失效
- 关闭tomcat
- 删除原来的项目文件
- 重启tomcat
- 观察日志
(后来才知道原来不需要关闭tomcat,当把旧war包改掉后缀,原来的项目文件就会自动删除,把新war包放上去之后,无需重启tomcat,新war包会自动解压自动生成项目文件)
不放心,又问了一下隔壁的同事,确认过没问题之后,开始操作了。操作的时候,还是很紧张,毕竟是第一次。好怕出了什么差错。
推上去没几分钟,客服那边就收到了很多好几个投诉电话,果然是出问题了,我当时看日志的时候,看到了很多通信接口未响应的错误提示,一脸懵逼。于是,马上把版本回退。
这是第一次推上线失败,失败之后,通过日志错误提示信息通信接口未响应,顺着提示的类名,我找到的相应的地方,最后发现是因为我没有将SocketClient类的测试端口改回正式端口,可我之前并不知道有这么个东西。这也说明了我对系统不熟悉,对代码不熟悉。确实如此。不过,其实readme文件里面有提示要改这个地方,只是我没留意。怪我。这次失败,让我感到压力好大。毕竟这是正式环境。齐跟我说,大哥,这app日交易金额不小的。不能这么随便啊。这让我压力更大了。
我也在日志中,发现了自己改进的日志功能,即logger语句的使用还是有问题。我把controller的各种logger语句封装到自己定义的静态类LogUtils类的几个静态方法里,想着这样以后修改就不需要每处都去修改。结果发现这样的日志记录显示的类与方法是LogUtils类的方法的位置,而不是具体controller类中的位置,这样一来我就没法通过日志知道具体是哪一个controller的哪个地方出了问题。
另外,钉钉机器人通知也没有生效。
总之,这波操作很失败。
##第二次推上线
第二次推上线是在星期一晚上10点多。经过第一次的教训,我们选择了晚上用户使用量较少的时候。这次推上线,用测试卡测试了圈存功能和解绑卡功能,都没问题。看了下日志,也没发现有什么问题(事实证明是我当时没看出来)。观察了一个多钟,齐那边也没反馈什么问题。11点多的时候,就去睡了。结果第二天得知版本又回退了。凌晨2点多的时候应该是收到投诉了吧,齐让另一个同事把版本回退了。
这是第二次推上线失败。第二天,齐又来说我了。压力真的好大。。。我也想弄好啊。齐说这次是绑卡有问题,我才想起昨天没有验证绑卡功能,由于之前就做了绑卡操作,就直接验证圈存功能了,忽略了绑卡功能的验证。看了下日志,没报什么错误啊。但是通过日志发现,在调用发送短信方法的时候,在doPost方法之前的日志都有输出,在doPost方法之后的日志却没有输出。齐哥说肯定是你发送短信验证码的方法出了问题。但是奇怪的是这个类我没有改过啊!!!超级郁闷。然后也发现,调用钉钉机器人通知的方法前的日志有输出,之后的日志却没输出,而且钉钉机器人通知方法里的logger也没有输出。这真的好奇怪。我以为是因为我加了ThreadLocal对象导致的问题。但是应该不是啊,因为我在我的毕设作品上加上ThreadLocal的使用也是没问题的啊。(使用THreadLocal是因为我在controller层的最后要通过logger将手机号码输出,但是手机号码的获取又是在service层,而我得把这个service层才获取到的手机号码传到controller层,因此我就通过ThreadLocal来实现,使用前也去了解过ThreadLocal的,是线程安全的,应该是没问题的啊)。但是现在我不得不怀疑是因为ThreadLocal的问题,尽管我在我的毕设作品上测试是没问题的。我调整了一下代码的顺序,先执行ThreadLocal的获取手机号码的方法,再通过logger语句输出手机号码,再调用钉钉机器人通知功能。至于发送验证码方法那里,我确实没改过什么,所以我也不管他了。
这波上线失败,完全没能确定问题所在。所以很担心下一次的上线,毕竟没改什么。
##第三次推上线
我真的真的,压力好大。压力之大还有另一个原因,星期二上午我跟部门经理说我周四周五要请假两天,他问我系统的功能弄好没,弄好才能请假,我瞬间就懵逼了,我说我一定要请的啊,他说那你尽量弄完吧。
我。。。。。。的毕业游。。。。。。难道就。。。。。。这样没了吗。。。。。。我钱都交了啊。。。。。。我是跟女同学一起去的a 。。。。。。
第三次推上线是在星期二的晚上11点半。我们选了个使用量小的时间段。
推上线前,齐说:“希望别再出问题了,我头痛”。我既感觉到好笑,但是又感到无奈。我也想成功啊,我也头痛啊哈哈。
第三次推上线了,对于替换新版本的那几个操作,已经麻木了,不紧张了。上线后,测试绑卡接口,马上就出问题了。超级尴尬。点击绑卡时,报了个500错误,系统内部错误:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sedgowcB-1575166274002)(https://i.imgur.com/iM93Ww2.png)]
很无奈,第三次上线,也失败了。
齐说:“这是你的接口啊。发送验证码啊。你是改了什么啊”
我好无奈啊,我真的没改过发送验证码方法啊。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bzjT7so1-1575166274003)(https://i.imgur.com/wTWuIcN.png)]
好无奈啊。。。想到我的毕业游,我就更烦躁了。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JLUJhVGJ-1575166274003)(https://i.imgur.com/aitLfZq.png)]
版本回退之后,问题就消失了。可是我真的没改过发送验证码的方法啊。我下载日志来看,确认了我使用ThreadLocal是没问题的。结合界面现实的额500内部错误,以及钉钉通知机器人方法执行前的logger语句有输出,之后的logger语句没输出,以及发送验证码doPost方法前的logger有输出,之后的logger没输出。开始猜测,这里有关联。于是,就去睡觉了。哈哈哈哈。但是,我能感觉到我找到问题了。
星期三早上,很早就起床了。继续研究日志。这钉钉机器人通知接口,我放在我的毕设上是能正常运行的,但是放到公司的项目里却不能正常运行。没加钉钉机器人通知功能的版本能正常发送短信,而加上去却不能。报了500内部错误。我想,难道是包依赖冲突?隐约在博客上看到过包依赖冲突的问题。于是上网找了一下,又在IDEA上捣鼓了一下项目中现在的包依赖关系,最后发现果然是这个问题。钉钉机器人通知功能用到的依赖httpcomponents和系统原来的一个httpcomponents冲突了。由于钉钉机器人通知功能需要用到更高版本的httpcomponents依赖(用系统原有的httpcomponents依赖会缺少一些类),但是我又担心把系统原有的httpcomponents依赖去掉的话,会影响原有的系统。因此我就直接把新的httpcomponents依赖加进去就不管了。没想到,两个不同版本的httpcomponents依赖放在一起会有问题。导致最后运行的时候还是缺少一些类。从而导致发送验证码方法有问题,钉钉机器人通知功能也有问题。这次我感觉我发现问题了!感觉,这次一定能成功了。我在毕设作品上把两个httpcomponents依赖都添加进去,测试一下,果然,钉钉通知机器人功能失效了。处理完这个问题之后,我相信这次一定能成功了。
##第四此推上线
星期三下午,刚好仪电那边会维护服务器,因此我们也趁机在2点他们恢复服务器的时候测试一波。
这次我信心满满,上线之后,测试,日志正常。期待了很久的钉钉机器人通知功能,也生效了!!!
总算是成功了!毕业游应该也没问题了!哈哈!也很庆幸,旅游期间,系统没出什么问题!证明我改动的功能是没问题的!
##感想
虽然,事后回过头来看看,好像遇到的问题也不是很复杂,但是由于没有经验,在此之前,没试过把系统推到正式环境上。也没考虑过包冲突依赖的问题。更因为没有测试环境,每次推上线都只能当成测试。也由于缺少老员工的指导,所以遇到什么问题都得自己去想,去解决。因此,会慢很多。好像别人一两个小时就能解决的问题,我得花上几天。
虽然,这几天没有熬夜或者通宵,但是,心却很累。期间一度怀疑自己,怀疑自己的智商,怀疑自己解决问题的能力。也一直祈求着能有人来帮自己。可是最后发现只能靠自己。这或许算是一点成长吧?
也总是在编程中发现一些有趣的事儿。这发送验证码接口,明明就没有改过,为什么就出了问题。很不可思议,很无法理解,更让我无法向齐解释。甚至怀疑是见鬼了。于我而言,这就好像我执行的是System.out.println("3")
,但是控制台输出的却是4
,这么不可思议。最后发现原来是因为包依赖冲突导致的,一下子就释怀了,总算是有个能接受的答案了!