最近接觸到兩個網站的重建，過程十分有趣，文字記錄一下吧，雖然沒有圖片，但如果以後你也碰到類似的，應該能理解。
說明
- 兩個網站是一起的，依賴的基本專案是一樣的。
- java專案，採用docker，多伺服器，主從。
- 有連線rds等
- 網站採用驗證碼登入
- 重構環境要求斷網環境
網站一
記錄所有伺服器的內網IP，根據對應的網段，為所有伺服器新增對應ip的虛擬網路卡，確保在IP地址不變的基礎上，大家可以互聯互通。
還原rds備份，並修改各個伺服器的hosts，將rds地址重定向到還原好的資料庫中，確保可以正常連線。
redis同理，按照配置檔案啟動一個即可，有密碼就配置密碼，一樣要修改hosts。
網站一啟動主要是需要先啟動幾個基本專案，docker直接啟動即可。
其中存在一個config專案，此專案會從git倉庫中拉取對應專案的yml配置檔案，config沒有正常啟動的話，其他專案都無法啟動。
- 其餘專案啟動時會找config要配置檔案，此時config會從git倉庫拉取
- docker中雖有編譯好的config，但它每次還是要從倉庫中拉取檔案，而不是返回自身jar包中的檔案
- config的配置檔案中已有倉庫地址及賬號密碼
config正常啟動方式
- 本地部署gitlab，配置好對應的域名、賬號與密碼
- 按照請求的專案路徑分別建立組和專案
- 反編譯config的jar包，將檔案上傳至gitlab的config專案
- 啟動config的docker容器
- 透過除錯/日誌中請求的地址嘗試請求一次yml配置檔案，成功即可
啟動前端，一般都是用的nginx，注意觀察配置檔案，以便修改本機的hosts。
後臺登入只能驗證碼登入，但是看後臺介面發現，有一個type值，值為1走密碼登入，其餘走驗證碼登入，這估計是從前可以使用不同的方式登入，後面就去掉了賬號密碼登入，但是服務端還沒有改。
透過抓包發現前端傳送請求，值固定為2。
bp攔截，修改type值為1後，可以正常觸發賬號密碼登入， 而不是手機驗證碼登入。
瀏覽器檢視原始碼，得知type值被寫死為2，在服務端修改原始碼，將值寫死為1，然後清除瀏覽器對這個檔案的快取，即可正常賬號密碼登入。
java網站的密碼加密方式，有多種解決方法。
- 直接抽出加密程式碼，本地執行，得到想要的密文。
- 分析加密邏輯，模擬加密行為。
- 透過專案日誌或者mysql的general_log，有時會以目前輸入的密碼的密文為查詢條件或者日誌給出。
網站二
大致邏輯與網站一相同，不過在服務端有專供賬號密碼登入的介面，直接訪問就可以繞過手機號驗證碼登入。
不同的是，在登入驗證密碼後，會向一個地址請求token，該地址不在掌握的資產當中，也沒有固定下來。
透過分析程式碼， 知道其請求返回的內容大致如下
{
"code":程式碼值,
"user":{
"token":token值
}
}解決方式：
- 使用tcpdump進行抓包，分析出傳送的請求的結構
- 使用Django進行介面開發， 對上述請求進行接收，並返回一個合理的資料，使專案可以正常獲取token，暫時不去關心token如何生成，有一個值即可
- 在gitlab中修改這個專案的配置檔案，將請求的地址改到django專案所在的地址
- 本地模擬一下請求，能夠正常返回後，再嘗試登入