今天，簡單的聊聊架構(gòu)方案，我們是如何平滑進(jìn)行機(jī)房遷移的。

【1】核心問題一，被遷移的系統(tǒng)是一個(gè)什么樣的架構(gòu)呢?

上圖是一個(gè)典型的互聯(lián)網(wǎng)單機(jī)房系統(tǒng)架構(gòu)：

• 上游是客戶端，PC瀏覽器或者APP;
• 然后是站點(diǎn)接入層，做了高可用集群;
• 接下來是服務(wù)層，服務(wù)層又分為兩層，業(yè)務(wù)服務(wù)層和基礎(chǔ)服務(wù)層，也都做了高可用集群;
• 底層是數(shù)據(jù)層，包含緩存與數(shù)據(jù)庫;

該單機(jī)房分層架構(gòu)，所有的應(yīng)用、服務(wù)、數(shù)據(jù)是部署在同一個(gè)機(jī)房，其架構(gòu)特點(diǎn)是“全連接”：

• 站點(diǎn)層調(diào)用業(yè)務(wù)服務(wù)層，業(yè)務(wù)服務(wù)復(fù)制了多少份，上層就要連接多少個(gè)服務(wù);
• 業(yè)務(wù)服務(wù)層調(diào)用基礎(chǔ)服務(wù)層，基礎(chǔ)服務(wù)復(fù)制了多少份，上層就要連多少個(gè)服務(wù);
• 服務(wù)層調(diào)用數(shù)據(jù)庫，數(shù)據(jù)庫冗余了多少份，就要連多少個(gè)數(shù)據(jù)庫;

例如：站點(diǎn)接入層某一個(gè)應(yīng)用有2臺機(jī)器，業(yè)務(wù)服務(wù)層某一個(gè)服務(wù)有4臺機(jī)器，那肯定是上游的2臺會與下游的4臺進(jìn)行一個(gè)全相連。

全連接如何保證系統(tǒng)的負(fù)載均衡與高可用?

全連接架構(gòu)的負(fù)載均衡與高可用保證，是通過連接池實(shí)現(xiàn)的。不管是NG連web，web連業(yè)務(wù)服務(wù)，業(yè)務(wù)服務(wù)連接基礎(chǔ)服務(wù)，服務(wù)連接數(shù)據(jù)庫，都是這樣。

劃重點(diǎn)1：單機(jī)房架構(gòu)的核心是“全連接”。

【2】核心問題二，機(jī)房遷移的目標(biāo)是什么?

單機(jī)房架構(gòu)的特點(diǎn)是“全連接”，機(jī)房遷移要做一個(gè)什么樣的事情呢?

如上圖：遷移之前，系統(tǒng)部署在機(jī)房A(M6)內(nèi)，是單機(jī)房架構(gòu)。遷移之后，系統(tǒng)部署在機(jī)房B(阿里云)內(nèi)，仍然是單機(jī)房架構(gòu)，只是換了一個(gè)機(jī)房而已。

有什么好的遷移方案?最容易想到的一個(gè)方案，把所有服務(wù)在新機(jī)房全都部署一套，然后把流量切過來。

這個(gè)方案存在什么問題?問題1：得停止服務(wù)，喪失了可用性。

問題2：即使可以接受停服，當(dāng)有幾百臺機(jī)器，幾千個(gè)系統(tǒng)的時(shí)候，“部署一套，切流量”一步成功的概率很低，風(fēng)險(xiǎn)極高，因?yàn)橄到y(tǒng)實(shí)在太復(fù)雜了。

機(jī)房遷移的難點(diǎn)，是“平滑”遷移，整個(gè)過程不停服務(wù)，并能夠“螞蟻搬家”式遷移。

劃重點(diǎn)2：機(jī)房遷移方案的設(shè)計(jì)目標(biāo)是：

• 平滑遷移，不停服務(wù);
• 可以分批遷移;
• 隨時(shí)可以回滾;

【3】核心問題三，暫時(shí)性的多機(jī)房架構(gòu)能否避免?

如果想要平滑的遷移機(jī)房，不停服務(wù)，且逐步遷移，遷移的過程中，勢必存在一個(gè)中間過渡階段，兩邊機(jī)房都有流量，兩邊機(jī)房都對外提供服務(wù)，這就是一個(gè)多機(jī)房的架構(gòu)。

遷移過程中，多機(jī)房架構(gòu)不可避免。

前文提到的單機(jī)房架構(gòu)，是一個(gè)“全連接”架構(gòu)，能不能直接將單機(jī)房的全連架構(gòu)套用到多機(jī)房呢?

如果直接將單機(jī)房“全連接”的架構(gòu)復(fù)制到多機(jī)房，會發(fā)現(xiàn)，會有很多跨機(jī)房的連接：

• 站點(diǎn)層連接業(yè)務(wù)服務(wù)層，一半的請求跨機(jī)房;
• 業(yè)務(wù)服務(wù)層連接基礎(chǔ)服務(wù)層，一半的請求跨機(jī)房;
• 基礎(chǔ)服務(wù)層連數(shù)據(jù)層，一半的請求跨機(jī)房;

大量的跨機(jī)房連接會帶來什么問題?同機(jī)房連接，內(nèi)網(wǎng)的性能損耗幾乎可以忽略不計(jì)。

一旦涉及到跨機(jī)房的訪問，即使機(jī)房和機(jī)房之間有專線，訪問的時(shí)延可能增加到幾毫秒，甚至幾十毫秒(跟機(jī)房間光纖距離有關(guān))。

舉個(gè)例子，假設(shè)戶訪問一個(gè)頁面，需要用到很多數(shù)據(jù)，這些數(shù)據(jù)可能需要20次相互調(diào)用(站點(diǎn)調(diào)用服務(wù)，服務(wù)調(diào)用緩存和數(shù)據(jù)庫等)，如果有一半調(diào)用跨機(jī)房(10次調(diào)用)，機(jī)房之間延遲是20毫秒，因?yàn)榭鐧C(jī)房調(diào)用導(dǎo)致的請求遲延就達(dá)到了200毫秒，這個(gè)是絕不能接受的。

劃重點(diǎn)3：想要平滑的實(shí)施機(jī)房遷移，臨時(shí)性的多機(jī)房架構(gòu)不可避免。

小結(jié)：

• 單機(jī)房架構(gòu)的核心是“全連接”。
• 機(jī)房遷移方案的設(shè)計(jì)目標(biāo)是：平滑遷移，不停服務(wù);可以分批遷移;隨時(shí)可以回滾;
• 想要平滑的實(shí)施機(jī)房遷移，臨時(shí)性的多機(jī)房架構(gòu)不可避免;

多機(jī)房架構(gòu)應(yīng)該如何設(shè)計(jì)?系統(tǒng)遷移步驟又該如何?今天累了，且聽明天分解。

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文