最近接觸到兩個網站的重建，過程十分有趣，文字記錄一下吧，雖然沒有圖片，但如果以后你也碰到類似的，應該能理解。

說明

• 兩個網站是一起的，依賴的基本項目是一樣的。
• java項目，采用docker，多服務器，主從。
• 有連接rds等
• 網站采用驗證碼登錄
• 重構環(huán)境要求斷網環(huán)境

網站一

記錄所有服務器的內網IP，根據(jù)對應的網段，為所有服務器添加對應ip的虛擬網卡，確保在IP地址不變的基礎上，大家可以互聯(lián)互通。

還原rds備份，并修改各個服務器的hosts，將rds地址重定向到還原好的數(shù)據(jù)庫中，確保可以正常連接。

redis同理，按照配置文件啟動一個即可，有密碼就配置密碼，一樣要修改hosts。

網站一啟動主要是需要先啟動幾個基本項目，docker直接啟動即可。

其中存在一個config項目，此項目會從git倉庫中拉取對應項目的yml配置文件，config沒有正常啟動的話，其他項目都無法啟動。

• 其余項目啟動時會找config要配置文件，此時config會從git倉庫拉取
• docker中雖有編譯好的config，但它每次還是要從倉庫中拉取文件，而不是返回自身jar包中的文件
• config的配置文件中已有倉庫地址及賬號密碼

config正常啟動方式

• 本地部署gitlab，配置好對應的域名、賬號與密碼
• 按照請求的項目路徑分別創(chuàng)建組和項目
• 反編譯config的jar包，將文件上傳至gitlab的config項目
• 啟動config的docker容器
• 通過調試/日志中請求的地址嘗試請求一次yml配置文件，成功即可

啟動前端，一般都是用的nginx，注意觀察配置文件，以便修改本機的hosts。

后臺登錄只能驗證碼登錄，但是看后臺接口發(fā)現(xiàn)，有一個type值，值為1走密碼登錄，其余走驗證碼登錄，這估計是從前可以使用不同的方式登錄，后面就去掉了賬號密碼登錄，但是服務端還沒有改。

通過抓包發(fā)現(xiàn)前端發(fā)送請求，值固定為2。

bp攔截，修改type值為1后，可以正常觸發(fā)賬號密碼登錄， 而不是手機驗證碼登錄。

瀏覽器查看源碼，得知type值被寫死為2，在服務端修改源碼，將值寫死為1，然后清除瀏覽器對這個文件的緩存，即可正常賬號密碼登錄。

java網站的密碼加密方式，有多種解決方法。

1. 直接抽出加密代碼，本地運行，得到想要的密文。
2. 分析加密邏輯，模擬加密行為。
3. 通過項目日志或者mysql的general_log，有時會以目前輸入的密碼的密文為查詢條件或者日志給出。

網站二

大致邏輯與網站一相同，不過在服務端有專供賬號密碼登錄的接口，直接訪問就可以繞過手機號驗證碼登錄。

不同的是，在登錄驗證密碼后，會向一個地址請求token，該地址不在掌握的資產當中，也沒有固定下來。

通過分析代碼， 知道其請求返回的內容大致如下

{
  "code":代碼值,
  "user":{
    "token":token值
  }
}

解決方式：

1. 使用tcpdump進行抓包，分析出發(fā)送的請求的結構
2. 使用Django進行接口開發(fā)， 對上述請求進行接收，并返回一個合理的數(shù)據(jù)，使項目可以正常獲取token，暫時不去關心token如何生成，有一個值即可
3. 在gitlab中修改這個項目的配置文件，將請求的地址改到django項目所在的地址
4. 本地模擬一下請求，能夠正常返回后，再嘗試登錄