一不小心又把应用发挂了,复盘一下这十几分钟的黑暗时刻
扫描二维码
随时随地手机看文章
晚上日常发布,无奈将应用发挂十几分钟,复盘一下,聊聊一下一些感悟。
晚上发布是一个渠道应用,主要作用为是去支付机构端进行银行卡扣款。
由于这个过程需要报文信息需啊哟在互联网中传输,所以需要进行相应的加签处理。
这里的银行卡等敏感信息需要采用 AES 加密,由于用于加密的私钥长度大于128位,JDK 自带的加密类将会抛出
java.security.InvalidKeyException: Illegal key size
从而导致加密失败。
加密工具类内部吃掉该异常,返回一个空字符串。然后我们上送给支付机构后,对方返回解密失败,从而导致此次交易失败。
解决办法很简单,更换如下目录的这两个 jar 包 local_policy.jar, US_export_policy.jar 。
${java_home}/jre/lib/security
参考如下:https://blog.csdn.net/wangjunjun2008/article/details/50847426
解决办法
上面说过只要更换这两个 jar 包就可以就解决问题,但是生产环境技术人员是没有权限,只能通过邮件审批,才能让运维人员去替换。
这个过程中涉及人员沟通,操作,快一点可能也要半小时。这让应用挂半小时,明天肯定得背个黑锅,肯定不行,得另想一个办法。
马上回滚应用,那也没办法,问题不是出在发布的应用上,而是 JDK 上。
有了,我们机器 Java 命令调用的是 JDK8 的路径,那我只要写死 java 命令绝对路径,就可以使用 JDK7 的路径,这样交易就可以正常进行。
想到了办法,立刻开干,替换了启动脚本的中 java 命令,成功将应用启动,交易运行也一切正常。
这时我们就可以慢慢来了,发送申请邮件,让运维人员替换 jar 包,然后再重新将之前写死绝对路径改回来,重新启动。
聊聊感想
这个问题其实在之前上线之处已经注意到了,当时我们使用 JDK1.7 ,上线之前已经更换了这两个包。但是前一段时间我们更换默认了 JDK,更换成 JDK8,该 JDK 没有更换这两个包,于是就炸了。
复盘一下今天的问题,现在回想,测试过程中,其实碰到过这个问题。但是当时我并没有引起重视,因为上次测试环境也更换过 JDK7 这两个 jar 包。所以我片面的认为该问题是公私钥配置的问题,所以就没有细查,最终导致该问题被带到了生产。
所以测试过程中,发生小问题,一定要引起重视,也不要过分自信认为都是小事,没什么影响。
刚发生这个问题的时候,说实话内心很慌,毕竟所有交易都会被阻塞。幸好这个问题也不是第一次碰到,很快就能想到解决办法。
但是如果是第一次碰到这类问题,根本没有经验,短时间内想不到解决办法咋办?
当然马上求助周围的同事,并跟自己的 Leader 反馈下这个问题。大家一起集思广益,解决这个问题。
不要想着自己死扛这个问题,自己一个人没思路的解决问题,很耽误时间的。
之前有个同事,生产出现问题,就喜欢一个人解决。但是如果你有办法解决,那也没问题。怕就怕这个同事不反馈,一个人夯吃夯吃在解决,到头来还是没解决。
这样就又拖延问题,很有可能就会小问题就会升级为大问题。说实话,这样说不准会让你的 Leader 反感。
特别推荐一个分享架构+算法的优质内容,还没关注的小伙伴,可以长按关注一下:
长按订阅更多精彩▼
如有收获,点个在看,诚挚感谢
免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!