今天早上很早就醒來，打開手機發現昨天晚上快12點的時候，我們業務經理打電話給我，然後我打開我們的APP，發現我們的APP報連接服務器錯誤，第一反應是我們的項目又內存溢出了。
由於這個項目是從外包手裏接手過來的，很多內容也沒有去優化，所以有時候會報內存溢出，所以自然而然地想到了這一方面。
打開服務器一看，有點詫異，服務器竟然沒有運行項目，然後我就自覺地把服務器重啓了下，還以爲是阿里雲自動重啓了。還自以爲是地給經理髮了個信息，說由於阿里雲自動重啓，所以昨晚的服務死掉了。以爲事情就這麼結束了。
結果一到公司，同事跟我說，昨天晚上服務器被人攻擊了，由於一時半會兒沒找到問題，他就直接把服務器停了，這才讓我意識到問題的嚴重性。
主要問題是昨天晚上有一個用戶在我們平臺下了很多單，通過支付寶付款，前端顯示都已經支付成功，但我們的支付寶賬戶沒有進一分錢。
由於整個項目是外包那邊接手過來的，現在又在開始開發新系統，所以裏面的很多風險都無法預測，接下來只有一一去排查問題了。
問題一：是否直接在我們的數據庫修改的信息
我們首先去看了下tomcat的日誌，看看他到底有沒有請求接口。後來想想也不太可能，服務器所有密碼都重新修改過，數據庫也已經做了遷移，現在只有內網能訪問，所以基本可以排除到這一點。那麼自然而然想到了第二點。
問題二：他們模擬了支付寶的回調
這讓我們感到有點不可思議，我們平臺才運行幾天，總共用戶也才幾百個，誰會花這麼大心思來搞我們這個東西呢。其實，我們做開發的明白，這個模擬請求是需要我們生成給支付寶的公鑰以及發給支付寶的參數才能這麼幹。我們心裏也明白，八九不離十是外包團隊乾的。不得不說，這也是我們的疏忽。
爲了驗證我們的想法，我們去查看了後臺數據，發現昨天晚上回調的支付寶訂單號根本就不是支付寶給我們的訂單號格式。
找到了問題的來源之後，接下來就是要想辦法解決了。
嘗試了很多方法：
方法一：嘗試去重新生成一個訂單號用於和支付寶校驗。
後來發現，這個訂單號，app端也是需要使用的，更大的坑是，支付寶的簽名竟然直接放在APP端，這樣如果要改的話，就要更新版本，代價太大。
方法二：修改支付寶的回調地址。
本來以爲是在支付寶的後臺修改的，後來發現又是在客戶端寫死的。
方法三：獲取回調地址的來源
本來以爲可以從request中獲取到，後來不知道是我們方法的問題，還是支付寶那邊做了處理，就是獲取不到回調地址的來源，只能放棄。
方法四：重新驗證
爲了保證數據的安全，只能犧牲一點效率。怎麼做呢？我們在支付寶回調之後，用支付寶給我們的參數，又去支付寶獲取了訂單詳情，如果可以正常獲取到，並且參數也正常的話，就判斷爲合法。這樣至少保證了數據的安全。
折騰了一天，最後不管怎樣，解決了問題，還是挺開心的。