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

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

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

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

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

特别推荐一个分享架构+算法的优质内容，还没关注的小伙伴，可以长按关注一下：长按订阅更多精彩▼如有收获，点个在看，诚挚感谢