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