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

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

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

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

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

java.security.InvalidKeyException: Illegal key size

從而導致加密失敗。

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

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

${java_home}/jre/lib/security

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

解決辦法

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

這個過程中涉及人員溝通，操作，快一點可能也要半小時。這讓應用掛半小時，明天肯定得背個黑鍋，肯定不行，得另想一個辦法。

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

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

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

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

聊聊感想

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

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

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

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

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

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

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

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

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

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