前情提要：

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

如上圖：

• 遷移之前，系統部署在機房A(M6)內，是單機房架構。
• 遷移之后，系統部署在機房B(阿里云)內，換了一個機房。

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

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

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

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

多機房多活架構，什么是理想狀態下的“同機房連接”?

如上圖所示，多機房多活架構，最理想狀態下，除了異步數據同步跨機房通訊，其他所有通訊均為“同機房連接”：

• web連業務服務;
• 業務服務連基礎服務;
• 服務連數據庫，主庫寫，從庫讀，讀寫分離;

上述架構，每個機房是一套獨立的系統，僅僅通過異步數據同步獲取全量數據，當發生機房故障時，將流量切到另一個機房，就能冗余“機房級”故障，實現高可用。

上述多機房架構存在什么問題?

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

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

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

從而導致：

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

上述架構適合于什么業務場景?

任何脫離業務的架構設計都是耍流氓。

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

典型的業務：滴滴，快狗打車。

這些業務具備數據聚集效應：

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

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

多機房多活架構，做不到理想狀態下的“同機房連接”，有沒有折中方案?

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

如上圖所示，在非必須的情況下，優先連接同機房的站點與服務：

• 站點層只連接同機房的業務服務層;
• 業務服務層只連接同機房的基礎服務層;
• 服務層只連接同機房的“讀”庫;
• 對于寫庫，沒辦法，只有跨機房讀“寫”庫了;

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

但互聯網的業務，絕大部分是讀多寫少的業務：

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

寫業務比例相對少，只有很少請求會跨機房調用。

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

偽多機房多活架構，有“主機房”和“從機房”的差別。

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

• 如果掛掉的是，不包含主庫的從機房，遷移流量后能直接容錯;
• 如果掛掉的是，包含主庫的主機房，只遷移流量，系統整體99%的讀請求可以容錯，但1%的寫請求會受到影響，此時需要將從庫變為主庫，才能完全容錯。這個過程需要DBA介入，不需要所有業務線上游修改。

畫外音：除非，站點和服務使用內網IP，而不是內網域名連接數據庫。架構師之路已經強調過很多次，不要使用內網IP，一定要使用內網域名。

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

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

小結：

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

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

思路比結論重要。

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

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