2015年的第一次通宵獻給了公司，作爲打雜的我與部門幾十個同事留下來通宵測試平臺預遷移之後的出現的問題，主要是爲了記錄下問題，以便接下來真正遷移的時候，可以提前把會出現的問題解決。
爲什麼是平臺遷移呢？因爲，公司的老的業務平臺積累了太多的用戶和數據，肯定沒辦法直接停掉去使用新的，但是如果新、舊兩套平臺同事存在，等以後業務量大了，要做調整和維護的話，那個難度太過於大。再者另一個原因，公司的平臺很大一部分是搜索引擎導向型，也就是非常依賴搜索引擎的收錄以及排名的。我們私底下都曾經笑稱，我們平臺都不是面向用戶的，是面對爬蟲的。於是只能夠採用，兼容老的URL是唯一的做法，所謂兼容老的URL，即對老的URL採用新的項目在後端進行響應，或者是採用重定向的方式。
爲什麼是半夜遷移呢？...因爲，根據前端訪問日誌可以看到從12點開始的爬蟲的訪問量開始降低...嘿嘿，夜深人靜就開始幹活了。
那我們在平臺遷移過程中會出現什麼問題呢?
1、樣式等靜態資源無法找到，因爲前端nginx的配置題，直接將部分站點的一些靜態資源請求還是到舊的後端去。
2、域名生效時間太慢，一些新域名要綁定線上的服務器的，生效時間出乎了預計的。
3、項目的版本控制沒做好，一個比較重要的站點，上線了未發佈的版本，導致部分接口無法調用。
4、數據庫壓力過大，導致SOA對web項目的響應時間過長，長時間佔用了jvm進程的工作線程，這個就導致了對應的web項目連靜態資源都無法請求響應了，其實也是對項目太自信。雖然之前已經刷了大量的舊站點的緩存，但是仍然有30%的訪問會壓到後端，把舊數據大量遷移到新平臺業務數據庫之後，庫的性能急劇下降，這些頁面的響應是由新平臺去響應的，結果直接卡死項目的響應了。
其實很多在測試環境無法測試出來的問題，在線上環境併發訪問較大的情況下，很容易就暴露出了很多問題。
呵呵，預遷移結束，又是遷回舊平臺，測試也告一段落。通宵後，回家休息了，第一試過這麼早下班哈...早上6點~~~~~~
