當年，我們是怎么平滑上云的？
今天，簡單的聊聊架構方案，我們是如何平滑進行機房遷移的。
【1】核心問題一，被遷移的系統是一個什么樣的架構呢?
上圖是一個典型的互聯網單機房系統架構：
- 上游是客戶端，PC瀏覽器或者APP;
- 然后是站點接入層，做了高可用集群;
- 接下來是服務層，服務層又分為兩層，業務服務層和基礎服務層，也都做了高可用集群;
- 底層是數據層，包含緩存與數據庫;
該單機房分層架構，所有的應用、服務、數據是部署在同一個機房，其架構特點是“全連接”：
- 站點層調用業務服務層，業務服務復制了多少份，上層就要連接多少個服務;
- 業務服務層調用基礎服務層，基礎服務復制了多少份，上層就要連多少個服務;
- 服務層調用數據庫，數據庫冗余了多少份，就要連多少個數據庫;
例如：站點接入層某一個應用有2臺機器，業務服務層某一個服務有4臺機器，那肯定是上游的2臺會與下游的4臺進行一個全相連。
全連接如何保證系統的負載均衡與高可用?
全連接架構的負載均衡與高可用保證，是通過連接池實現的。不管是NG連web，web連業務服務，業務服務連接基礎服務，服務連接數據庫，都是這樣。
劃重點1：單機房架構的核心是“全連接”。
【2】核心問題二，機房遷移的目標是什么?
單機房架構的特點是“全連接”，機房遷移要做一個什么樣的事情呢?
如上圖：遷移之前，系統部署在機房A(M6)內，是單機房架構。遷移之后，系統部署在機房B(阿里云)內，仍然是單機房架構，只是換了一個機房而已。
有什么好的遷移方案?最容易想到的一個方案，把所有服務在新機房全都部署一套，然后把流量切過來。
這個方案存在什么問題?問題1：得停止服務，喪失了可用性。
問題2：即使可以接受停服，當有幾百臺機器，幾千個系統的時候，“部署一套，切流量”一步成功的概率很低，風險極高，因為系統實在太復雜了。
機房遷移的難點，是“平滑”遷移，整個過程不停服務，并能夠“螞蟻搬家”式遷移。
劃重點2：機房遷移方案的設計目標是：
- 平滑遷移，不停服務;
- 可以分批遷移;
- 隨時可以回滾;
【3】核心問題三，暫時性的多機房架構能否避免?
如果想要平滑的遷移機房，不停服務，且逐步遷移，遷移的過程中，勢必存在一個中間過渡階段，兩邊機房都有流量，兩邊機房都對外提供服務，這就是一個多機房的架構。
遷移過程中，多機房架構不可避免。
前文提到的單機房架構，是一個“全連接”架構，能不能直接將單機房的全連架構套用到多機房呢?
如果直接將單機房“全連接”的架構復制到多機房，會發現，會有很多跨機房的連接：
- 站點層連接業務服務層，一半的請求跨機房;
- 業務服務層連接基礎服務層，一半的請求跨機房;
- 基礎服務層連數據層，一半的請求跨機房;
大量的跨機房連接會帶來什么問題?同機房連接，內網的性能損耗幾乎可以忽略不計。
一旦涉及到跨機房的訪問，即使機房和機房之間有專線，訪問的時延可能增加到幾毫秒，甚至幾十毫秒(跟機房間光纖距離有關)。
舉個例子，假設戶訪問一個頁面，需要用到很多數據，這些數據可能需要20次相互調用(站點調用服務，服務調用緩存和數據庫等)，如果有一半調用跨機房(10次調用)，機房之間延遲是20毫秒，因為跨機房調用導致的請求遲延就達到了200毫秒，這個是絕不能接受的。
劃重點3：想要平滑的實施機房遷移，臨時性的多機房架構不可避免。
小結：
- 單機房架構的核心是“全連接”。
- 機房遷移方案的設計目標是：平滑遷移，不停服務;可以分批遷移;隨時可以回滾;
- 想要平滑的實施機房遷移，臨時性的多機房架構不可避免;
多機房架構應該如何設計?系統遷移步驟又該如何?今天累了，且聽明天分解。
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
