一不小心又把應(yīng)用發(fā)掛了，復(fù)盤一下這十幾分鐘的黑暗時(shí)刻

晚上日常發(fā)布，無奈將應(yīng)用發(fā)掛十幾分鐘，復(fù)盤一下，聊聊一下一些感悟。

晚上發(fā)布是一個(gè)渠道應(yīng)用，主要作用為是去支付機(jī)構(gòu)端進(jìn)行銀行卡扣款。

由于這個(gè)過程需要報(bào)文信息需啊喲在互聯(lián)網(wǎng)中傳輸，所以需要進(jìn)行相應(yīng)的加簽處理。

這里的銀行卡等敏感信息需要采用 AES 加密，由于用于加密的私鑰長度大于128位，JDK 自帶的加密類將會拋出

java.security.InvalidKeyException: Illegal key size

從而導(dǎo)致加密失敗。

加密工具類內(nèi)部吃掉該異常，返回一個(gè)空字符串。然后我們上送給支付機(jī)構(gòu)后，對方返回解密失敗，從而導(dǎo)致此次交易失敗。

解決辦法很簡單，更換如下目錄的這兩個(gè) jar 包 local_policy.jar, US_export_policy.jar 。

${java_home}/jre/lib/security

參考如下：https://blog.csdn.net/wangjunjun2008/article/details/50847426

解決辦法

上面說過只要更換這兩個(gè) jar 包就可以就解決問題，但是生產(chǎn)環(huán)境技術(shù)人員是沒有權(quán)限，只能通過郵件審批，才能讓運(yùn)維人員去替換。

這個(gè)過程中涉及人員溝通，操作，快一點(diǎn)可能也要半小時(shí)。這讓應(yīng)用掛半小時(shí)，明天肯定得背個(gè)黑鍋，肯定不行，得另想一個(gè)辦法。

馬上回滾應(yīng)用，那也沒辦法，問題不是出在發(fā)布的應(yīng)用上，而是 JDK 上。

有了，我們機(jī)器 Java 命令調(diào)用的是 JDK8 的路徑，那我只要寫死 java 命令絕對路徑，就可以使用 JDK7 的路徑，這樣交易就可以正常進(jìn)行。

想到了辦法，立刻開干，替換了啟動腳本的中 java 命令，成功將應(yīng)用啟動，交易運(yùn)行也一切正常。

這時(shí)我們就可以慢慢來了，發(fā)送申請郵件，讓運(yùn)維人員替換 jar 包，然后再重新將之前寫死絕對路徑改回來，重新啟動。

聊聊感想

這個(gè)問題其實(shí)在之前上線之處已經(jīng)注意到了，當(dāng)時(shí)我們使用 JDK1.7 ，上線之前已經(jīng)更換了這兩個(gè)包。但是前一段時(shí)間我們更換默認(rèn)了 JDK，更換成 JDK8，該 JDK 沒有更換這兩個(gè)包，于是就炸了。

復(fù)盤一下今天的問題，現(xiàn)在回想，測試過程中，其實(shí)碰到過這個(gè)問題。但是當(dāng)時(shí)我并沒有引起重視，因?yàn)樯洗螠y試環(huán)境也更換過 JDK7 這兩個(gè) jar 包。所以我片面的認(rèn)為該問題是公私鑰配置的問題，所以就沒有細(xì)查，最終導(dǎo)致該問題被帶到了生產(chǎn)。

所以測試過程中，發(fā)生小問題，一定要引起重視，也不要過分自信認(rèn)為都是小事，沒什么影響。

剛發(fā)生這個(gè)問題的時(shí)候，說實(shí)話內(nèi)心很慌，畢竟所有交易都會被阻塞。幸好這個(gè)問題也不是第一次碰到，很快就能想到解決辦法。

但是如果是第一次碰到這類問題，根本沒有經(jīng)驗(yàn)，短時(shí)間內(nèi)想不到解決辦法咋辦？

當(dāng)然馬上求助周圍的同事，并跟自己的 Leader 反饋下這個(gè)問題。大家一起集思廣益，解決這個(gè)問題。

不要想著自己死扛這個(gè)問題，自己一個(gè)人沒思路的解決問題，很耽誤時(shí)間的。

之前有個(gè)同事，生產(chǎn)出現(xiàn)問題，就喜歡一個(gè)人解決。但是如果你有辦法解決，那也沒問題。怕就怕這個(gè)同事不反饋，一個(gè)人夯吃夯吃在解決，到頭來還是沒解決。

這樣就又拖延問題，很有可能就會小問題就會升級為大問題。說實(shí)話，這樣說不準(zhǔn)會讓你的 Leader 反感。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠摯感謝