前情提要：

《當年，我們是怎么平滑上云的?》一文中提到了上云的背景，將所有的系統(tǒng)，從一個機房，遷移到另一個機房。

如上圖：

• 遷移之前，系統(tǒng)部署在機房A(M6)內(nèi)，是單機房架構(gòu)。
• 遷移之后，系統(tǒng)部署在機房B(阿里云)內(nèi)，換了一個機房。

《當年，我們是怎么平滑上云的?》有三結(jié)論：

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

【4】核心問題四，臨時性多機房架構(gòu)如何實施?

如前文所述，如果將單機房“全連接”架構(gòu)復(fù)制到多機房，會有大量跨機房調(diào)用，極大增加請求時延，是業(yè)務(wù)無法接受的，要想降低這個時延，必須實施“同機房連接”。

多機房多活架構(gòu)，什么是理想狀態(tài)下的“同機房連接”?

如上圖所示，多機房多活架構(gòu)，最理想狀態(tài)下，除了異步數(shù)據(jù)同步跨機房通訊，其他所有通訊均為“同機房連接”：

• web連業(yè)務(wù)服務(wù);
• 業(yè)務(wù)服務(wù)連基礎(chǔ)服務(wù);
• 服務(wù)連數(shù)據(jù)庫，主庫寫，從庫讀，讀寫分離;

上述架構(gòu)，每個機房是一套獨立的系統(tǒng)，僅僅通過異步數(shù)據(jù)同步獲取全量數(shù)據(jù)，當發(fā)生機房故障時，將流量切到另一個機房，就能冗余“機房級”故障，實現(xiàn)高可用。

上述多機房架構(gòu)存在什么問題?

“異步數(shù)據(jù)同步”存在延時(例如：1min)，這個延時的存在，會使得兩個機房的數(shù)據(jù)不一致，從而導(dǎo)致嚴重的業(yè)務(wù)問題。

舉個例子，某一個時刻，用戶X有余額100元，兩個機房都存儲有該余額的精準數(shù)據(jù)，接下來：

• 余額100，X在北京(就近訪問機房A)消費了80元，余額僅剩20元，該數(shù)據(jù)在1分鐘后會同步到機房B;
• 余額100，X的夫人在廣州(就近訪問機房B)用X的賬號消費了70元，余額剩余30元，該數(shù)據(jù)在1分鐘后也會同步到機房A;

從而導(dǎo)致：

• 超額消費(100余額，卻買了150的東西);
• 余額異常(余額是20，還是30?);

上述架構(gòu)適合于什么業(yè)務(wù)場景?

任何脫離業(yè)務(wù)的架構(gòu)設(shè)計都是耍流氓。

當每個機房都有很多全局業(yè)務(wù)數(shù)據(jù)的訪問場景時，上述多機房架構(gòu)并不適用，會存在大量數(shù)據(jù)不一致。但當每個機房都訪問局部業(yè)務(wù)數(shù)據(jù)時，上述多機房架構(gòu)仍然是可行的。

典型的業(yè)務(wù)：滴滴，快狗打車。

這些業(yè)務(wù)具備數(shù)據(jù)聚集效應(yīng)：

• 下單用戶在同一個城市;
• 接單司機在同一個城市;
• 交易訂單在同一個城市;

這類業(yè)務(wù)非常適合上述多機房多活架構(gòu)，多個機房之間即使存在1分鐘延時的“異步數(shù)據(jù)同步”，對業(yè)務(wù)也不會造成太大的影響。

多機房多活架構(gòu)，做不到理想狀態(tài)下的“同機房連接”，有沒有折中方案?

如果完全避免跨機房調(diào)用的理想狀態(tài)做不到，就盡量做到“最小化”跨機房調(diào)用。

如上圖所示，在非必須的情況下，優(yōu)先連接同機房的站點與服務(wù)：

• 站點層只連接同機房的業(yè)務(wù)服務(wù)層;
• 業(yè)務(wù)服務(wù)層只連接同機房的基礎(chǔ)服務(wù)層;
• 服務(wù)層只連接同機房的“讀”庫;
• 對于寫庫，沒辦法，只有跨機房讀“寫”庫了;

該方案沒有完全避免跨機房調(diào)用，但它做到了“最小化”跨機房調(diào)用，只有寫請求是跨機房的。

但互聯(lián)網(wǎng)的業(yè)務(wù)，絕大部分是讀多寫少的業(yè)務(wù)：

• 百度的搜索100%是讀業(yè)務(wù);
• 京東淘寶電商99%的瀏覽搜索是讀業(yè)務(wù)，只有下單支付是寫業(yè)務(wù);
• 58同城99%帖子的列表詳情查看是讀業(yè)務(wù)，只有發(fā)布帖子是寫業(yè)務(wù);

寫業(yè)務(wù)比例相對少，只有很少請求會跨機房調(diào)用。

該多機房多活架構(gòu)，并沒有做到100%的“同機房連接”，通常稱作偽多機房多活架構(gòu)。

偽多機房多活架構(gòu)，有“主機房”和“從機房”的差別。

多機房多活架構(gòu)的初衷是容機房故障，該架構(gòu)當出現(xiàn)機房故障時，可以把入口處流量切到另一個機房：

• 如果掛掉的是，不包含主庫的從機房，遷移流量后能直接容錯;
• 如果掛掉的是，包含主庫的主機房，只遷移流量，系統(tǒng)整體99%的讀請求可以容錯，但1%的寫請求會受到影響，此時需要將從庫變?yōu)橹鲙欤拍芡耆蒎e。這個過程需要DBA介入，不需要所有業(yè)務(wù)線上游修改。

畫外音：除非，站點和服務(wù)使用內(nèi)網(wǎng)IP，而不是內(nèi)網(wǎng)域名連接數(shù)據(jù)庫。架構(gòu)師之路已經(jīng)強調(diào)過很多次，不要使用內(nèi)網(wǎng)IP，一定要使用內(nèi)網(wǎng)域名。

偽多機房多活架構(gòu)，是一個實踐性，落地性很強的架構(gòu)，它對原有架構(gòu)體系的沖擊非常小，和單機房架構(gòu)相比，僅僅是：

• 跨機房主從同步數(shù)據(jù)，會多10毫秒延時;畫外音：主從同步數(shù)據(jù)，本來就會有延時。
• 跨機房寫，會多10毫秒延時;

小結(jié)：

• 理想多機房多活架構(gòu)，是純粹的“同機房連接”，僅有異步數(shù)據(jù)同步會跨機房;
• 理想多機房多活架構(gòu)，會有較嚴重數(shù)據(jù)一致性問題，僅適用于具備數(shù)據(jù)聚集效應(yīng)的業(yè)務(wù)場景，例如：滴滴，快狗打車;
• 偽多機房多活架構(gòu)，思路是“最小化跨機房連接”，機房區(qū)分主次，落地性強，對原有架構(gòu)沖擊較小，強烈推薦;

臨時性多機房多活架構(gòu)，是機房遷移過程中的一個過渡狀態(tài)，機房遷移步驟又該如何?且聽明天分解。

思路比結(jié)論重要。

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

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