又到周末了，周更选手申请出站~ 这次分享一下上个月碰到的离奇的问题。一个简单的问题，硬是因为异常被悄咪咪吃掉，过关难度直线提升，导致小黑哥排查一个晚上。 这个美好的晚上，本想着开两把 LOL 无限火力，在召唤师峡谷来个五杀的~ 哎，就这样没了啊！我知道，你们一定能理解这种五杀被抢的感觉~ 下次，真的，谁再让我看到悄咪咪的吃掉异常，我真的要上去一 Jio 了！ 好了，本文可不是水文，看完本篇文章，你可以学到以下知识点： Arthas 排查技巧 啥是 NoClassDefFoundError Dubbo 异常内部处理方式 好了，同学们，打开小本子，准备记好知识点~ 起因 我们有个业务系统，应用之间调用链如下所示： A 应用是业务发生起始应用，在这个应用中将会根据一定规则选择最后的通讯渠道 C，然后将这个渠道标识传递给 B 应用。 B 应用的功能类似网关，这个应用将会根据 A 应用传递过来的渠道标识，将会请求路由下发到具体的 C 应用，起到服务路由的功能。 C 应用是与外部应用交互的应用，我们将其称为渠道通讯机。 假设一次业务中，A 应用根据规则选择 C2 的渠道标识，然后传递给.... 谁再悄咪咪的吃掉异常，我上去就是一 JIO Dubbo
晚上日常发布，无奈将应用发挂十几分钟，复盘一下，聊聊一下一些感悟。 晚上发布是一个渠道应用，主要作用为是去支付机构端进行银行卡扣款。 由于这个过程需要报文信息需啊哟在互联网中传输，所以需要进行相应的加签处理。 这里的银行卡等敏感信息需要采用 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 包就可以就解决问题，但是生产环境技术人员是没有权限，只能通过邮件审批，.... 一不小心又把应用发挂了，复盘一下这十几分钟的黑暗时刻 小黑黑的碎碎念
小黑十一点半