一不當心又把應用發掛了，覆盤一下這十幾分鐘的黑暗時刻

晚上平常發佈，無奈將應用發掛十幾分鍾，覆盤一下，聊聊一下一些感悟。

晚上發佈是一個渠道應用，主要做用爲是去支付機構端進行銀行卡扣款。

因爲這個過程須要報文信息需啊喲在互聯網中傳輸，因此須要進行相應的加簽處理。

這裏的銀行卡等敏感信息須要採用 AES 加密，因爲用於加密的私鑰長度大於128位，JDK 自帶的加密類將會拋出

java.security.InvalidKeyException: Illegal key size

從而致使加密失敗。

加密工具類內部吃掉該異常，返回一個空字符串。而後咱們上送給支付機構後，對方返回解密失敗，從而致使這次交易失敗。

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

${java_home}/jre/lib/security

解決辦法

上面說過只要更換這兩個 jar 包就能夠就解決問題，可是生產環境技術人員是沒有權限，只能經過郵件審批，才能讓運維人員去替換。

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

立刻回滾應用，那也沒辦法，問題不是出在發佈的應用上，而是 JDK 上。

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

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

這時咱們就能夠慢慢來了，發送申請郵件，讓運維人員替換 jar 包，而後再從新將以前寫死絕對路徑改回來，從新啓動。

聊聊感想

這個問題其實在以前上線之處已經注意到了，當時咱們使用 JDK1.7 ，上線以前已經更換了這兩個包。可是前一段時間咱們更換默認了 JDK，更換成 JDK8，該 JDK 沒有更換這兩個包，因而就炸了。

覆盤一下今天的問題，如今回想，測試過程當中，其實碰到過這個問題。可是當時我並無引發重視，由於上次測試環境也更換過 JDK7 這兩個 jar 包。因此我片面的認爲該問題是公司鑰配置的問題，因此就沒有細查，最終致使該問題被帶到了生產。

因此測試過程當中，發生小問題，必定要引發重視，也不要過度自信認爲都是小事，沒什麼影響。

剛發生這個問題的時候，說實話心裏很慌，畢竟全部交易都會被阻塞。幸虧這個問題也不是第一次碰到，很快就能想到解決辦法。

可是若是是第一次碰到這類問題，根本沒有經驗，短期內想不到解決辦法咋辦？

固然立刻求助周圍的同事，並跟本身的 Leader 反饋下這個問題。你們一塊兒集思廣益，解決這個問題。

不要想着本身死扛這個問題，本身一我的沒思路的解決問題，很耽誤時間的。

以前有個同事，生產出現問題，就喜歡一我的解決。可是若是你有辦法解決，那也沒問題。怕就怕這個同事不反饋，一我的夯吃夯吃在解決，到頭來仍是沒解決。

這樣就有拖延問題，頗有可能就會小問題就會升級爲大問題。說實話，這樣說不許會讓你的 Leader 反感。

好了，不知不覺，就寫 1000 多字，但願你們有一些幫助。