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

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

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

因为这个过程须要报文信息需啊哟在互联网中传输，因此须要进行相应的加签处理。

这里的银行卡等敏感信息须要采用 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 半夜~