記一次亞馬遜雲平台遷移過程中的經驗教訓

  發布人:超級管理員   發布時間:2015年08月18日 12:00  閱讀:965

     在向亞馬遜雲平台的遷移過程中,踩了不少坑,收獲也很多。由于系統的遷移涉及各個常見的架構組件,邊邊角角的細節很多。和大部分系統一樣,長時間野蠻成長積累了很多問題。這樣的老系統遷移到新平台意味著你需要處理所有之前埋下的問題。


最近 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. 運維難度的降低,無需運維

系統會自動根據負載進行增減機器,所以無需擔心壓力大把機器打垮,單機器的各種故障也無需人工處理。


【關閉本頁】 【打印本頁】 【返回頂部】
Copyright © 1997-2019  南京同慶科技有限公司 蘇ICP備05085873號-1 地址:南京市洪武北路188號603室 電話:025-57907999