方案背景
隨著互聯(lián)網(wǎng)業(yè)務(wù)快速發(fā)展，多IDC的業(yè)務(wù)支撐能力和要求也逐步提升，行業(yè)內(nèi)的“兩地三中心”方案較為流行。
其中兩地是指同城、異地；三中心是指生產(chǎn)中心、同城容災(zāi)中心、異地容災(zāi)中心。
在早期，比較典型的是國內(nèi)外銀行多采用“兩地三中心”建設(shè)方案。這種模式下，多個數(shù)據(jù)中心是主備關(guān)系，即存在主次，業(yè)務(wù)部署優(yōu)先級存在差別，針對災(zāi)難的響應(yīng)與切換周期非常長，RTO與RPO目標(biāo)無法實現(xiàn)業(yè)務(wù)零中斷，資源利用率低下，投資回報無法達到預(yù)期。兩地三中心本質(zhì)上是一種通過簡單資源堆砌提高可用性的模式，對高可用的提高、業(yè)務(wù)連續(xù)性的保證仍然只是量變，業(yè)務(wù)連續(xù)性及容災(zāi)備份一直沒有實質(zhì)性的跨越。
目前，以銀行為代表的、包括政府、公共交通、能源電力等諸多行業(yè)用戶，開始將關(guān)注點轉(zhuǎn)向“分布式多活數(shù)據(jù)中心”
通過雙活的方案，具有兩類特點。一是多IDC中心之間地位均等，在正常模式下協(xié)同工作，并行的為業(yè)務(wù)訪問提供服務(wù)，實現(xiàn)了對資源的充分利用，避免一個或兩個備份中心處于閑置狀態(tài)，造成資源與投資浪費，通過資源整合，多活數(shù)據(jù)中心的服務(wù)能力往往雙倍甚至數(shù)倍于主備數(shù)據(jù)中心模式；二是在一個數(shù)據(jù)中心發(fā)生故障或災(zāi)難的情況下，其他數(shù)據(jù)中心可以正常運行并對關(guān)鍵業(yè)務(wù)或全部業(yè)務(wù)實現(xiàn)接管，達到互為備份的效果，實現(xiàn)用戶的“故障無感知”。
結(jié)合公司目前的業(yè)務(wù)運營情況，IDC機房主要在xxxx,xxx,同時在xxxx區(qū)域部署有一些IDC機房，其中數(shù)據(jù)中心主要以xxx為主，所以在兩地三中心方案中，同城雙活較為符合發(fā)展的趨勢。
而兩地三中心方案的設(shè)計，不光需要數(shù)據(jù)庫層基于分布式進行改造，同時在業(yè)務(wù)層，系統(tǒng)層，網(wǎng)絡(luò)層都需要相關(guān)的方案適配。
目標(biāo)和計劃：
ü 兩地三中心的設(shè)計原則為同城雙活，異地容災(zāi)，其中同城暫定為HB30,HB21,異地容災(zāi)暫定為華中或華東的IDC節(jié)點
ü 改造設(shè)計需要和業(yè)務(wù)端進行密切配合，從業(yè)務(wù)場景出發(fā)選擇合適的方案
ü 考慮跨機房的支持，需要引入consul方案，實現(xiàn)service_name的高可用管理
ü 同城雙活的數(shù)據(jù)要求為最終一致性，異地容災(zāi)暫不對業(yè)務(wù)開放，在30分鐘內(nèi)可以快速恢復(fù)業(yè)務(wù)
ü 可以設(shè)定短期目標(biāo)和長期目標(biāo)，短期目標(biāo)可以充分借助開源紅利和業(yè)務(wù)場景進行落地，在落地過程中不斷的迭代改進；長期目標(biāo)可以選擇更為通用，技術(shù)挑戰(zhàn)較大，業(yè)務(wù)效果好的方案（如異地多活）。
ü 為了確保方案的有效，需要定期進行演練
方案簡介
兩地三中心方案中，基于設(shè)定的短期目標(biāo)可以明確同城雙活和異地容災(zāi)的方案組合。
則設(shè)計重點為同城雙活，即在同城的數(shù)據(jù)中心之間，一般通過高速光纖相連，在網(wǎng)絡(luò)帶寬有保障的前提下，網(wǎng)絡(luò)延遲一般在可接受范圍內(nèi)，兩個機房之間可以認為在同一個局域網(wǎng)內(nèi)。
在設(shè)計上可以和應(yīng)用層結(jié)合起來，有兩種部署模式：分為應(yīng)用層雙活和數(shù)據(jù)庫雙活，應(yīng)用層雙活和數(shù)據(jù)庫單活。
1）
.應(yīng)用層雙活和數(shù)據(jù)庫單活方案：
應(yīng)用層雙活，數(shù)據(jù)庫單活：兩個機房的應(yīng)用程序同時對外提供服務(wù)，但是只有一個機房的數(shù)據(jù)庫提供讀寫，另外一個機房的應(yīng)用程序需要跨機房訪問數(shù)據(jù)庫，數(shù)據(jù)庫之間單向復(fù)制。該模式在網(wǎng)絡(luò)延遲相對低的同城環(huán)境下表現(xiàn)良好，但是如果距離超過100 公里，機房之間的網(wǎng)絡(luò)延遲就會超過2ms（或者更高），此時對于跨機房訪問的數(shù)據(jù)庫請求，性能有較大影響。
針對同城網(wǎng)絡(luò)延遲低，可以看作是同一個局域網(wǎng)的特點，對于應(yīng)用雙活+數(shù)據(jù)庫單活的方案，應(yīng)用跨機房訪問數(shù)據(jù)庫，一旦某個機房故障，則將另外一個機房的應(yīng)用訪問請求切換到本機房的數(shù)據(jù)庫，從而實現(xiàn)同城任何一個數(shù)據(jù)中心出現(xiàn)故障，都不會影響到整體業(yè)務(wù)的運行。
由于同城之間網(wǎng)絡(luò)條件相對較好，MySQL 數(shù)據(jù)庫原生的復(fù)制模式能夠滿足大部分業(yè)務(wù)場景，MySQL 5.7 推出的并行復(fù)制可以有效解決容災(zāi)機房日志回放慢的問題，在5.7.17推出的MGR/InnoDB Cluster則可以實現(xiàn)數(shù)據(jù)的強一致需求。
方案一：MGR集群多活架構(gòu)
整個架構(gòu)是基于分布式方案來設(shè)計，節(jié)點通信基于協(xié)議Paxos，MGR作為InnoDB Cluster的核心組件，目前支持單主模式和多主模式，本方案優(yōu)先采用單主模式，節(jié)點數(shù)至少2-9個節(jié)點。
基于MGR的多活的設(shè)計方案如下，在數(shù)據(jù)庫層通過優(yōu)先在本機房的實例節(jié)點設(shè)置權(quán)重，優(yōu)先切換到同機房，在同機房出現(xiàn)故障的情況下，切換到同城異機房。
以上方案的實施成本較低，對業(yè)務(wù)的侵入較少，適用于跨機房容災(zāi)的初級階段的用戶。
2） 應(yīng)用層雙活，數(shù)據(jù)庫雙活方案
應(yīng)用層雙活和數(shù)據(jù)庫雙活：兩個機房的應(yīng)用程序同時對外提供服務(wù)，兩個機房的數(shù)據(jù)庫也同時提供讀寫，每個機房的應(yīng)用程序讀寫同一個機房內(nèi)的數(shù)據(jù)庫，兩個數(shù)據(jù)庫之間雙向復(fù)制，通過一致性協(xié)議解決雙向?qū)憶_突問題，該模式理論上實現(xiàn)了數(shù)據(jù)庫多點寫入，但是在實際跨機房場景中，尤其是在寫沖突密集的業(yè)務(wù)場景下，性能下降非常大，不適用于跨機房的OLTP 系統(tǒng)。
而對于應(yīng)用雙活+數(shù)據(jù)庫多活的方案，需要重點考慮數(shù)據(jù)延遲和數(shù)據(jù)同步的問題。首先需要在業(yè)務(wù)上做隔離，數(shù)據(jù)目標(biāo)為最終一致性，目前存在如下的五類方案。
方案一：MGR集群多活架構(gòu)
可以基于MGR的多活特性，數(shù)據(jù)的寫入可以在多個節(jié)點之間進行復(fù)制，實現(xiàn)數(shù)據(jù)強一致性需求，并且在節(jié)點間通信出現(xiàn)延遲的情況下，會自動實現(xiàn)服務(wù)降級。
對于此類方案，我們可以采用同機房多寫，同城異機房只讀的方案。
方案二：分布式數(shù)據(jù)同步
基于分布式設(shè)計方案，可以引入數(shù)據(jù)組件syncer和writer,實現(xiàn)機房多活的業(yè)務(wù)需求，syncer和writer為數(shù)據(jù)的發(fā)布者和消費者，基于分布式協(xié)議進行處理。
在處理過程中有三類關(guān)鍵技術(shù)：
1）數(shù)據(jù)的處理基于分布式ID，能夠唯一定位數(shù)據(jù)處理操作，并且該操作具備遞增趨勢。
2）同步組件的穩(wěn)定性，同步組件可以理解為一種通用服務(wù)，需要考慮不同機房間的數(shù)據(jù)延遲和數(shù)據(jù)沖突處理機制，保證同步組件服務(wù)的穩(wěn)定，高效。
3）同步組件的高可用，對于同步組件需要根據(jù)業(yè)務(wù)特點做權(quán)重處理，考慮不通IDC的業(yè)務(wù)情況，并重點考慮同步組件的數(shù)據(jù)冗余設(shè)計，保證發(fā)生異常時能夠及時恢復(fù)數(shù)據(jù)。
此種方案短期內(nèi)難以實現(xiàn)，但是長期來看，可以支持機房多活，業(yè)務(wù)價值更高。
方案三：雙主模式的多活
對于數(shù)據(jù)庫原生的雙主模式，兩個節(jié)點均可以寫入數(shù)據(jù)，可以實現(xiàn)跨機房的數(shù)據(jù)復(fù)制，延遲較低，在業(yè)務(wù)層需要做隔離，在故障發(fā)生時能夠快速切換到同機房的Slave節(jié)點。
此方案對于兩個IDC機房的場景中較為實用，但是機房多活的場景不適合。
方案四：業(yè)務(wù)交叉的雙活方案
此種方案是雙活技術(shù)的變通實現(xiàn)，即存在兩類業(yè)務(wù)A和B,數(shù)據(jù)存儲在database級別（schema層級），分別在不通的IDC節(jié)點完成數(shù)據(jù)寫入，比如業(yè)務(wù)A在IDC1完成寫入，業(yè)務(wù)B在IDC2完成寫入，兩個節(jié)點之間存在跨機房的復(fù)制節(jié)點，在出現(xiàn)問題時，能夠通過域名的方式切換到指定的IDC節(jié)點。
此種方案對于業(yè)務(wù)的依賴性較高，不適合機房多活的場景。
方案五：基于NewSQL的改造方案
可以參考行業(yè)內(nèi)的NewSQL開源解決方案，原生支持MySQL協(xié)議。
比如PolarDB,Sequoia，TiDB等。
歡迎大家拋磚引玉，后續(xù)跟進閱讀量考慮要不要繼續(xù)展開。：）
相關(guān)鏈接：
http://www.info2soft.com/6291.html
http://www.h3c.com/cn/d_201307/790142_30008_0.htm
