记一次打包的诡异现象
一、前情提要:
今天线上打包,发现启动正常,但是访问异常,看日志也没有打印出什么异常信息。
更新的微服务包访问的时候一直报出【403】,访问被拒
项目架构:springBoot + maven
二、机缘巧合:
上午出现这个问题当场没有找到解决办法,明明启动正常怎么就访问不了?先放下了这个问题
下午另一个项目调试,也是部署到服务器后,访问拒绝,当时怀疑打包配置有问题,我就在本地自己打了包部署上去,项目启动正常!!!
这是怎么回事?使用比对工具首先发现,包里少了某些功能代码,但是这不该是影响运行的理由啊?
之后再看其它的不同,发现依赖的一个基础包【common】里少了几个依赖包,并且mavne的pom配置也不尽相同
【判定:是打包环节出了问题】
三、后知后觉:
现在想想,特定的包访问被拒绝,而所有的包都依赖【common】包,应该想到是特定包打包的时候,依赖包不一致导致的
项目都是【eureka】的,不能访问,而不是报错,访问权限控制,不就是依赖的【common】包里的配置吗?
所以,打包的话,尽量一次全打,哪怕只用其中一个,保证基础依赖包唯一
单独打包的话,可能导致,引用了上次的【common】包,或者在本地存在的本身就有异常的【common】包
【原因猜想-1:目标包是单独打的,基础依赖包出错】
【原因猜想-2:打包的机器,maven工具出了问题,依赖错误或者依赖缺失】
四、总结:
针对这种框架,如果服务部署运行正常,而配置又没有问题的话,好好的就是不能访问,那么就【重新打包】试试,说不定就好了
不要钻死胡同,一切都正常了,无法排查原因了,就不要自己瞎想了
看着正常,但是不行,那就换一个试试,不要纠结,换一个好了,就对比,看哪里不一样,方便下次排查
我从不相信什么懒洋洋的自由,
我向往的自由是通过勤奋和努力实现更广阔的人生,那样的自由才是珍贵的、有价值的。
我相信一万小时定律,我从来不相信天上掉馅饼的灵感和坐等的成就。
做一个自由又自律的人,靠势必实现的决心认真地活着。
我向往的自由是通过勤奋和努力实现更广阔的人生,那样的自由才是珍贵的、有价值的。
我相信一万小时定律,我从来不相信天上掉馅饼的灵感和坐等的成就。
做一个自由又自律的人,靠势必实现的决心认真地活着。
[山本耀司]
本文转载请注明出处