2015年底的時候，到家集團啟動了一個「凌雲」項目，將所有系統從北京的M6機房遷移到阿里雲，完成技術棧「上雲」。項目涉及幾百台機器，到家所有的業務，所有的系統，需要所有技術部門配合，耗時超過一個季度，是一個不折不扣的大項目。
今天，簡單的聊聊當時的架構方案，我們是如何平滑進行機房遷移的。
上圖是一個典型的互聯網單機房系統架構：
（1）上游是客戶端，PC瀏覽器或者APP；
（2）然後是站點接入層，做了高可用集群；
（3）接下來是服務層，服務層又分為兩層，業務服務層和基礎服務層，也都做了高可用集群；
（4）底層是數據層，包含緩存與資料庫；
該單機房分層架構，所有的應用、服務、數據是部署在同一個機房，其架構特點是「全連接」：
（1）站點層調用業務服務層，業務服務複製了多少份，上層就要連接多少個服務；
（2）業務服務層調用基礎服務層，基礎服務複製了多少份，上層就要連多少個服務；
（3）服務層調用資料庫，資料庫冗餘了多少份，就要連多少個資料庫；
例如：站點接入層某一個應用有2台機器，業務服務層某一個服務有4台機器，那肯定是上游的2台會與下游的4台進行一個全相連。
全連接如何保證系統的負載均衡與高可用？
全連接架構的負載均衡與高可用保證，是通過連接池實現的。不管是NG連web，web連業務服務，業務服務連接基礎服務，服務連接資料庫，都是這樣。
劃重點1：
單機房架構的核心是「全連接」。
如上圖：
遷移之前，系統部署在機房A（M6）內，是單機房架構。
遷移之後，系統部署在機房B（阿里雲）內，仍然是單機房架構，只是換了一個機房而已。
最容易想到的一個方案，把所有服務在新機房全都部署一套，然後把流量切過來。
問題2：即使可以接受停服，當有幾百台機器，幾千個系統的時候，「部署一套，切流量」一步成功的概率很低，風險極高，因為系統實在太複雜了。
機房遷移的難點，是「平滑」遷移，整個過程不停服務，並能夠「螞蟻搬家」式遷移。
【3】核心問題三，暫時性的多機房架構能否避免？
如果想要平滑的遷移機房，不停服務，且逐步遷移，遷移的過程中，勢必存在一個中間過渡階段，兩邊機房都有流量，兩邊機房都對外提供服務，這就是一個多機房的架構。
前文提到的單機房架構，是一個「全連接」架構，能不能直接將單機房的全連架構套用到多機房呢？
如果直接將單機房「全連接」的架構複製到多機房，會發現，會有很多跨機房的連接：
（2）業務服務層連接基礎服務層，一半的請求跨機房；
一旦涉及到跨機房的訪問，即使機房和機房之間有專線，訪問的時延可能增加到幾毫秒，甚至幾十毫秒（跟機房間光纖距離有關）。
舉個例子，假設戶訪問一個頁面，需要用到很多數據，這些數據可能需要20次相互調用（站點調用服務，服務調用緩存和資料庫等），如果有一半調用跨機房（10次調用），機房之間延遲是20毫秒，因為跨機房調用導致的請求遲延就達到了200毫秒，這個是絕不能接受的。
想要平滑的實施機房遷移，臨時性的多機房架構不可避免。
（2）機房遷移方案的設計目標是：平滑遷移，不停服務；可以分批遷移；隨時可以回滾；
（3）想要平滑的實施機房遷移，臨時性的多機房架構不可避免；
喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！
