記一次亞馬遜云平臺遷移過程中的經驗教訓
最近 3 個月變化很多，離開呆了 5 年多的北京，開始英國的工作和生活。到這之后基本在做系統向亞馬遜云平臺的遷移，踩了不少坑，收獲也很多。由于系統的遷移涉及各個常見的架構組件，邊邊角角的細節很多。和大部分系統一樣，長時間野蠻成長積累了很多問題。這樣的老系統遷移到新平臺意味著你需要處理所有之前埋下的問題。公司之前聘請了亞馬遜推薦的第三方咨詢服務工作在做遷移，但是由于問題太多，拖了很長時間沒有完成。
成熟老系統常見的問題：
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. 運維難度的降低，無需運維
系統會自動根據負載進行增減機器，所以無需擔心壓力大把機器打垮，單機器的各種故障也無需人工處理。
