一. 為何要做多機房
單一機房機房不可用時，業(yè)務停止，數據無法訪問。不同地域的用戶請求響應延時不同，CDN只能解決靜態(tài)資源訪問加速。多機房可以備份用戶和系統數據，保證數據安全，一個機房出現故障可以切換到另外機房，提高系統可用性，按用戶地域合理分配，訪問就近的機房。
二. 理論依據
根據不同行業(yè)，以及CAP的三選二原則，支付、交易要求強一致（不允許出現臟數據），屬于CA，互聯網對強一致性要求不高，對可用性要求較高，一般都采用AP 弱一致性架構，也就是BSAE，BASE理論是eBay的架構師Dan Pritchett在ACM上發(fā)表文章提出的，BASE是指基本可用（Basically Available）、軟狀態(tài)（Soft State）、最終一致性（Eventual Consistency），允許窗口期數據不一致。
三 具體實踐
1、新機房建設
IDC機房選購
選型、招標、參觀機房、評審、商務談判、合同簽署、開通寬帶
網絡架構設計及評審
服務器/網絡設備選購
設備選型、招標、商務談判、合同簽署、設備采購，資產管理
模擬網絡架構測試
網絡/VPN/標簽等規(guī)劃、雙網卡綁定測試、模擬交換機/鏈路冗余測試、模擬VPN測試、防火墻冗余測試、負載均衡測試、專線網絡測試
基礎設施部署
IDC開通機柜帶寬、設備驗貨、上架基礎設施、部署基礎設置
應用服務部署
自動裝機系統、自動化運維系統、KVM虛擬化、賬號管理系統、DNS系統、資產管理、監(jiān)控系統、nginx、haproxy、keepalived、tomcat、redis、mq、zk、fastdfs、mysql、sqlserver、應用代碼
2、切換數據中心方案設計
數據中心測試方案設計
數據中心切換方案設計
部署架構
整體的切換原則是平滑遷移，不停服務。
3、數據中心切換過程
遷移之前，確保新機房代碼是最新的，測試人員進行回歸測試，DBA部署亦莊到武清的數據庫（sqlserver、mysql）、redis同步關系，文件系統，mq等都類似。
第一天凌晨進行第一波流量切換，切山東節(jié)點到武清機房，大約5%左右的流量，觀察服務狀況，沒有異常情況，用戶可正常下單。
第二天凌晨進行第二波流量切換， 上海、江蘇、浙江、四川、河南、河北、福建大約50%左右的流量，繼續(xù)觀察服務狀況，沒有異常情況，用戶可正常下單。
第三天凌晨進行全部切換，包括數據庫等，切到武清做主，數據直接寫武清的庫。運維在DNSPOD上進行，把其他剩余流量切換到武清，切換后，網絡工程師觀察亦莊是否還有流量進入，因為DNS有緩存，所以需要觀察一段時間，待到沒有流量進入，開始進行存儲層切換：
1、sqlserver，DBA利用手動故障轉移，將vip從亦莊機房切換搭武清機房，停掉亦莊的sqlserver，sqlserver切換結束。
2、redis，DBA利用批處理腳本關掉亦莊所有redis主庫實例，完成后，主庫自動切換到武清，亦莊所有redis實例不提供任何服務， 不會有任何臟數據產生，運維切換DNS，DNS生效后，redis切換結束。
3、mysql，和redis切換方式類似，DBA利用批處理腳本殺掉主庫，保證沒有臟數據進來，運維切換DNS，生效后，mysql切換結束。
以上全部遷移OK后，所有流量、數據、存儲都在新機房了，亦莊機房用于災備。
四. 經驗總結
系統比較多，大大小小的100多個系統，梳理過程中不夠謹慎 ，遺漏了一些問題， 操作過程中，亦莊到武清做了很多調整，沒有做好調研，整理了很多文檔，做了很多工作，有不細致的地方，有些工作需要確認，沒有落實到書面上，測試過程中有些不清楚的地方，欠缺溝通，信息不同步，準備工作沒有準備好，還有歷史遺漏原因。
遷移的過程中，有盲點，有測試不到的地方， 支付， 物流，小服務，全量push無法測試， 遷移后pay不可用， push不可用， dns解析問題導致部分緩存流量還在亦莊， 預案做的不充分，雖然有些問題，不過整體上來說，這次數據中心切換還算比較成功。
