本文由 網易雲 發布。
作者：郭憶 來自：網易雲 基礎服務
近年來，我們經常可以看到某某公司因為機房電力故障或者機房網絡光纖被市政施工挖斷導致整個數據中心服務不可用，進而對產品和業務產生嚴重影響的事件的發生。
隨着互聯網產品對服務可用性，數據可靠性要求的進一步提高，原先的單機房集中部署模式已經不能滿足要求，跨機房部署的需求越來越多。
“兩地三中心” 已經是跨機房災備的標准技術架構，通常會在相距 40 公里范圍以內的同座城市建設災備數據中心，應對機房級別的故障。之所以將距離鎖定在 40 公里范圍以內是考慮到這個距離通過高速光纖相連，機房之間的響應延遲一般在 1ms 左右，從業務層面講可以認為是在同一個局域網內。
除了同城災備，“兩地三中心” 的方案還包括在相距 1000 公里以外的兩個不同城市組建異地災備數據中心，應對區域性故障，不過由於距離長度的限制，機房之間的網絡延遲難以避免。
“兩地三中心” 的技術架構最早在銀行和金融行業應用實施，但一般都只有一個機房提供服務，其他的災備機房僅同提供服務的生產機房進行數據復制，這種冷備的模式並不適用於互聯網業務：
維護成本過高：由於只有生產機房提供服務，同城的災備機房和異地災備機房都處於空閑狀態，隨着業務數據量和訪問量的增長，需要花費三倍的成本去維護災備機房，對於互聯網業務海量數據和高並發訪問的特點，維護成本過高。
切換時間無法保障：由於只有生產機房是提供服務的，災備機房沒有承擔業務的訪問請求，一旦生產機房出現故障，災備機房的啟用和預熱都需要花費一定的時間，同時由於該機房之前沒有提供服務，在啟用過程中難免會存在各種問題，由此導致的切換時間難以保障，無法滿足互聯網業務對實時性的要求。
難以擴展：由於整個架構是單點寫入，數據庫很容易成為性能瓶頸，而數據庫的擴展方案非常復雜，導致整個架構的擴展也變得難以實施。
接下來，我們就來談談適用於互聯網業務的 “互聯網版” 兩地三中心架構：
同城雙活
在同城的數據中心之間，一般通過高速光纖相連，在網絡帶寬有保障的前提下，網絡延遲一般在可接受范圍內，兩個機房之間可以認為在同一個局域網內。該架構下，有兩種部署模式：
應用層雙活，數據庫雙活：兩個機房的應用程序同時對外提供服務，兩個機房的數據庫也同時提供讀寫，每個機房的應用程序讀寫同一個機房內的數據庫，兩個數據庫之間雙向復制，通過一致性協議解決雙向寫沖突問題（例如 MySQL 5.7.17 推出的 Group Replication Plugin），該模式理論上實現了數據庫多點寫入，但是在實際跨機房場景中，尤其是在寫沖突密集的業務場景下，性能下降非常大，不適用於跨機房的 OLTP 系統。
應用層雙活，數據庫單活：兩個機房的應用程序同時對外提供服務，但是只有一個機房的數據庫提供讀寫，另外一個機房的應用程序需要跨機房訪問數據庫，數據庫之間單向復制。該模式在網絡延遲相對低的同城環境下表現良好，但是如果距離超過 100 公里，機房之間的網絡延遲就會超過 2ms，此時對於跨機房訪問的數據庫請求，性能有較大影響。
針對同城網絡延遲低，可以看作是同一個局域網的特點，應用層采用雙活，數據庫采用單活是相對合理的方案。應用跨機房訪問數據庫，一旦某個機房故障，則將另外一個機房的應用訪問請求切換到本機房的數據庫，從而實現同城任何一個數據中心出現故障，都不會影響到整體業務的運行。
由於同城之間網絡條件相對較好，MySQL 數據庫原生的復制性能一般能夠滿足要求，MySQL 5.7 推出的並行復制可以有效解決容災機房日志回放慢的問題。
同城雙活相對實施成本較低，對業務的侵入較少，適用於跨機房容災的初級階段的用戶。此外，為了確保方案的有效，還需要定期進行演練。
異地多活
當兩個機房之間的距離超過 1000 公里，機房之間的網絡傳輸延遲已經無法支撐跨機房的數據庫訪問請求的實時性要求，此時要實現多活，難度增加，需要從業務架構和數據庫層進行改造。
單元化：將業務按照一定的維度拆分成獨立的單元，每個單元內包含完整的基礎設施，包括應用程序、數據庫、消息隊列等，單元內是封閉的，每個單元內部的應用訪問和數據庫讀寫均在同一個單元內部完成，單元之間僅允許少量的服務調用，這樣就很好地解決了跨單元訪問延遲的問題。
單元化的核心在於選擇一個合理的維度，例如在電商的業務場景中，買家鏈路是交易系統的核心，所以電商類業務基於買家來做數據拆分是一個相對合理的選擇，在游戲、郵箱、社交類業務中，可以基於用戶維度進行數據拆分。數據拆分后，每個單元的數據庫中只負責一部分數據的讀寫，所以要確保業務請求必須路由到正確的單元中，否則就會出現數據庫讀寫的錯亂。
數據傳輸：雖然按照買家維度，將同一個買家的所有交易信息都在同一個單元的數據庫中寫入，但是商品信息、賣家信息還是需要在不同單元之間進行共享，這就涉及單元之間數據同步的問題。由於跨域的原因，網絡延遲無法避免，但是我們可以通過壓縮的方式，減少日志的傳輸量，提高復制的效率。
原生 MySQL 的復制並不支持壓縮功能，可以基於第三方的外部組件來實現壓縮的特性，網易的 NDC 已實現了該功能。
異地多活在一定程度上可以有效地提高產品和業務應對區域故障的能力，確保出現故障的情況下絕大多數用戶的核心體驗可用。但是不可否認，異地多活的實施成本和代價也是非常高昂的，尤其是面對迭代節奏非常快的互聯網業務，所以異地多活適用於業務模型已經趨於穩定的應用。但即便如此，在實施過程中，也要有針對性地選擇核心和關鍵業務，並不是所有的業務都需要異地多活的部署。
單元化的應用架構，還有一個顯著優勢就是擴展性，由於每個單元相互獨立，負責處理一部分的業務請求和一部分的數據讀寫，當業務請求數量或者數據量增長時，只需要通過增加單元，即可實現整個系統處理能力的線性擴展。
了解 網易雲 ：
網易雲官網：https://www.163yun.com/
新用戶大禮包：https://www.163yun.com/gift
網易雲社區：https://sq.163yun.com/