今天,遇到一个https post请求返回405的错误,错误的现象时,有些接口有时候访问正常,有时候访问出错,随即google了一下,说是nginx下访问通过post方式访问静态资源有时候会返回405的错误!然后认真看了一下代码,代码是用Spring MVC框架返回视图,中间就include了一个.jsp的文件,不可能是静态的资源啊!然后没办法,跟OP那边的项目负责人沟通,跟IOS客户端开发的妹子沟通(要改请求访问方式,从post改成get),一番下来,差不多一个小时。然后op那边的负责人问我要了一个case去测试,发现nginx那边也没有什么问题,后来,op负责人说了一句;貌似resin s1-5都有问题,我觉得奇怪,用postman测试了一下,果然,resin实例从s1-5都返回405的错误码(其中,没有resin实例表示的都部署在虚机上,s1-5都部署在同一台实体机上,是五个实例),道是resin问题?我从resin的配置到log错误日志输出到resin的版本号都对了一遍,发现都是一样的没有问题,说明实机和虚机都是一样的,不会是resin的问题。然后,又对nginx的配置进行了逐一比较,发现也没有问题,(nginx的安装配置都是公司统一的配置格式,不会有问题),现在,毫无头绪啊!为什么在实机上有问题,而虚机上没有问题?
之后,终于发现问题的所在了!我在实机上面看了一下源代码,发现部署的代码并不是最新上线的master分支的代码!什么,怎么会这样?我之后又重新部署了一遍,发现还是原来的代码,问题终于找到症结了!原来实机在上线之前做了隔离,用脚本部署代码完全拉不下来gitlab上的分支!靠,真TM想抽自己!之后从其他虚机上scp了最新master分支的代码,编译运行,ok,问题解决!之前部署代码是就没有看中间的输出,直接看服务启动了没有,这忽略了很多重要的细节!
总结:自己无论是写程序还是做其他事情,都是丢三落四!没有一个全神贯注的去做一个事情,所以总是会写一个有很多bug的程序,然后不断的recoding debug recoding debug,浪费了很多时间,所以,今后一定要养成一个很严谨的工作态度,认真谨慎!同时,遇到问题,一定要多思考,多观察Bug现象,做出合理推测,也要和测试那边多沟通,协调工作!