將網站遷移到亞馬遜云會遇到哪些問題?做系統向亞馬遜云平臺的遷移，踩了不少坑，收獲也很多。由于系統的遷移涉及各個常見的架構組件，邊邊角角的細節很多。和大部分系統一樣，長時間野蠻成長積累了很多問題。這樣的老系統遷移到新平臺意味著你需要處理所有之前埋下的問題。公司之前聘請了亞馬遜推薦的第三方咨詢服務工作在做遷移，但是由于問題太多，拖了很長時間沒有完成。
一、網站遷移亞馬遜成熟老系統常見的問題：
1.
缺乏文檔：這應該是大小公司都存在的問題。文檔會極大降低開發效率，并且互聯網項目的特點是易變和追求速度，詳細文檔不是很好的方案。這就要求方案和細節設計上的合理性和不要做
“精巧”方案。結構化設計，不要零散的組成，這樣其他人即使沒有文檔也可以理解。
2.
項目中臨時方案太多：導致后來看起來很別扭而且不容易理解;半截工程。系統中存在大量“精巧”的設計，導致后來者難以理解。這也告訴我們做設計的時候盡量簡單通俗易懂，項目設計的可溝通性也是很重要的一方面。某位工程師說自己花了
1 周的時間才搞明白 Postfix 的收郵件并自動解析的過程是怎么運行的。
3. 代碼質量參差不齊：代碼質量問題每個大點的團隊都沒法保證，保持代碼庫的干凈很重要。
4. 繁雜的業務
5. 代碼的 BUG 和代碼對環境的兼容性
之前的系統使用配置文件做主從讀寫分離，配置文件由其他系統控制。但是配置文件確保留在代碼庫中，這意味著假如代碼回滾或者 check
分支出錯，配置文件會發生改變。不該發生的全會發生，這樣的事情確實發生了。導致部分操作寫入從庫，從庫與主庫同步失敗，典型的腦裂問題。最后只好花了很長時間重做從庫的同步。這樣的問題處理并不復雜，復雜的在于如何發現這個問題的原因。業務系統各種奇怪的表現，有時候很難想到問題的根源。
二、網站遷移亞馬遜過程需要考慮的問題：
1.
完善測試：性能測試可以采取流量鏡像復制，讀操作有很多簡單可靠的流量復制工具，有時候根本不需要一個高大上的流量復制系統。并且大部分系統都是讀多寫少，測試不是什么難題。
功能性測試只能盡量做足，讓熟悉系統的用戶進行。
2. 無縫遷移：整個過程基本實現了平滑無縫遷移，系統的沒有停止 1 分鐘運行。由于項目的特點，比較少寫操作，重點是讀，暫停寫操作后作將 HaProxy
后端逐步指向新集群，等全部流量導入新集群后修改 DNS 指向新集群。這里還涉及到 DNS TTL 從長變短再變長的修改過程。
緩存預熱很重要，尤其是數據庫的預熱，這就要求新集群流量導入逐步進行，防止對整站延遲的影響。
3. 回退方案：由于暫時停止寫操作，即使流量導入到新集群后測試發現問題仍然可以指回舊集群。
4. 改進還是保持原狀：由于架構組件的選擇余地很大，之前的各個組件的配置是否合理需要很長時間
Review。這里就要權衡保持原狀還是一次性做好優化。比較好的方案是如果不是 BUG 則保持原狀，等系統完成遷移再進行改進。
5. 性能的持續監控和對比測試：性能監控工具已經非常成熟了，比如 AppNeta 和 New Relic ,
基本可以把控各個組件的性能。在遷移之前也可以進行鏡像流量復制對比測試新舊集群的性能。
三、網站遷移亞馬遜有哪些優勢?
1. 重新設計的發布自動化：業務代碼、系統配置、云架構配置的分離，任何操作的版本化，可回退。
2. 彈性擴展，總體成本的降低：遷移到亞馬遜的主要原因就是高低峰流量差異很大。遷移后低峰期可以節約 1 半的機器成本。
3. 跨區域容災，無單點故障：實現了 Multi-AZ，任意單點故障不影響業務運行。Web
前端服務器可以隨手關掉，數據庫的升級，配置改動也無任何影響，當然這歸功于 RDS Multi-AZ 功能。
4. 運維難度的降低，無需運維：系統會自動根據負載進行增減機器，所以無需擔心壓力大把機器打垮，單機器的各種故障也無需人工處理。
關于亞馬遜云平臺的特點和各個組件以后還會有單獨的文章詳細解釋。
上一篇：
怎么選擇合適的，2E5香港大寬帶服務器？
下一篇：
海外云服務器網絡錯誤ping不通是什么原因？
