一不小心又把应用发挂了，复盘一下这十几分钟的黑暗时刻
# 小黑黑的碎碎念
晚上日常发布，无奈将应用发挂十几分钟，复盘一下，聊聊一下一些感悟。
晚上发布是一个渠道应用，主要作用为是去支付机构端进行银行卡扣款。
由于这个过程需要报文信息需啊哟在互联网中传输，所以需要进行相应的加签处理。
这里的银行卡等敏感信息需要采用 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 半夜~
本文首发于: https://studyidea.cn/error_bug
欢迎关注我的公众号：程序通事，获得日常干货推送。如果您对我的专题内容感兴趣，也可以关注我的博客：studyidea.cn
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
