您的位置:首页 > 其它

一不小心又把应用发挂了,复盘一下这十几分钟的黑暗时刻

2020-08-04 23:11 816 查看

晚上日常发布,无奈将应用发挂十几分钟,复盘一下,聊聊一下一些感悟。

晚上发布是一个渠道应用,主要作用为是去支付机构端进行银行卡扣款。

由于这个过程需要报文信息需啊哟在互联网中传输,所以需要进行相应的加签处理。

这里的银行卡等敏感信息需要采用 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 反感。

好了,不知不觉,就写 1000 多字,希望大家有一些帮助。

2020.05.14 半夜~

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐