［翟娜 彭亮 左繪 江思源 廖江 惲天翔］

1 引言

隨著互聯(lián)網(wǎng)的發(fā)展，線上業(yè)務(wù)的穩(wěn)定性變得越來(lái)越重要。政務(wù)、教育、互聯(lián)網(wǎng)、醫(yī)療、制造等各行業(yè)對(duì)線上服務(wù)入口依賴度都越來(lái)越高，對(duì)新功能上線速度、網(wǎng)站的可用性要求同樣非常高。為了保證系統(tǒng)正常、穩(wěn)定地運(yùn)行，企業(yè)的IT 部門(mén)通常都制定了嚴(yán)格的上線、運(yùn)維流程和制度，對(duì)關(guān)鍵的服務(wù)和數(shù)據(jù)做冗余和備份。然而即使有嚴(yán)格的流程管控和數(shù)據(jù)備份，單機(jī)房仍然可能遇到大面積基礎(chǔ)設(shè)施故障、網(wǎng)絡(luò)入口故障，停電等，甚至極個(gè)別嚴(yán)重的軟件故障也可能導(dǎo)制網(wǎng)站停止服務(wù)。因此對(duì)于金融、電信等關(guān)系到線上業(yè)務(wù)和數(shù)據(jù)即生命線的企業(yè)，通常會(huì)建“主備”、“多活”、“兩地三中心”的跨資源池容災(zāi)系統(tǒng)，以便在發(fā)生機(jī)房級(jí)故障時(shí)，及時(shí)切換到另一個(gè)可用機(jī)房，繼續(xù)提供服務(wù)，保障業(yè)務(wù)連續(xù)性。大型的互聯(lián)網(wǎng)、金融行業(yè)，如阿里、餓了么、銀行等，一般都實(shí)現(xiàn)了核心業(yè)務(wù)一定程度的雙活、多活架構(gòu)，參考文獻(xiàn)[1,4,6,9]中運(yùn)營(yíng)商也對(duì)網(wǎng)絡(luò)設(shè)計(jì)、容災(zāi)技術(shù)、數(shù)據(jù)中心設(shè)計(jì)等做了大量的研究，但總體來(lái)看方案仍存在總體成本較高，與業(yè)務(wù)系統(tǒng)存在較大的緊耦合、復(fù)雜架構(gòu)下容災(zāi)協(xié)調(diào)困難等問(wèn)題。因此探索有效利用電信網(wǎng)絡(luò)技術(shù)與云計(jì)算技術(shù)，支持低應(yīng)用侵入、低延時(shí)網(wǎng)絡(luò)、高一致性保障且可以推廣復(fù)用的跨資源池高可用解決方案是需要重點(diǎn)解決的問(wèn)題。

跨資源池高可用從層級(jí)上來(lái)說(shuō)可以分為數(shù)據(jù)級(jí)容災(zāi)、應(yīng)用級(jí)容災(zāi)、以及業(yè)務(wù)級(jí)容災(zāi)。數(shù)據(jù)級(jí)容災(zāi)是通過(guò)數(shù)據(jù)備份、復(fù)制等方式，在遠(yuǎn)程設(shè)備上備份數(shù)據(jù)，確保故障發(fā)生后數(shù)據(jù)不會(huì)丟失或者遭到破壞。備份與復(fù)制不同，在發(fā)生誤刪除等操作情況下，復(fù)制技術(shù)會(huì)導(dǎo)致遠(yuǎn)程數(shù)據(jù)也被刪除，但備份數(shù)據(jù)存在一定的延時(shí)，復(fù)制技術(shù)又分為同步與異步方式，如果需要達(dá)到零數(shù)據(jù)丟失，則往往需要依靠復(fù)制技術(shù)來(lái)實(shí)現(xiàn)，參考文獻(xiàn)[3,7]都對(duì)數(shù)據(jù)庫(kù)復(fù)制技術(shù)進(jìn)行了研究。應(yīng)用級(jí)容災(zāi)是在數(shù)據(jù)級(jí)容災(zāi)的基礎(chǔ)之上，在遠(yuǎn)程設(shè)備同時(shí)部署運(yùn)行一套相同的應(yīng)用系統(tǒng)，保證關(guān)鍵應(yīng)用在允許的時(shí)間范圍內(nèi)恢復(fù)運(yùn)行，盡可能減少災(zāi)難帶來(lái)的損失，應(yīng)用級(jí)容災(zāi)往往需要通過(guò)更多的軟硬件組件協(xié)同來(lái)實(shí)現(xiàn)，除了數(shù)據(jù)復(fù)制，還需要有包括網(wǎng)絡(luò)、主機(jī)、應(yīng)用、甚至IP等資源。業(yè)務(wù)級(jí)容災(zāi)除了相關(guān)IT應(yīng)用系統(tǒng)，還需要對(duì)辦公場(chǎng)所等非IT系統(tǒng)進(jìn)行容災(zāi)。

天翼物聯(lián)PaaS平臺(tái)為應(yīng)用上云提供了分布式數(shù)據(jù)庫(kù)、分布式緩存、分布式消息隊(duì)列、容器服務(wù)、DevOps開(kāi)發(fā)運(yùn)營(yíng)一體化、微服務(wù)框架、日志監(jiān)控等能力，資源分布在多個(gè)資源池，平臺(tái)上承載的CRM、計(jì)費(fèi)、賬務(wù)、5G CMP等重要業(yè)務(wù)系統(tǒng)對(duì)跨資源池的高可用運(yùn)行與應(yīng)用級(jí)容災(zāi)提出了需求。物聯(lián)網(wǎng)某核心平臺(tái)的總體技術(shù)架構(gòu)如圖1所示。本文將著重介紹跨資源池業(yè)務(wù)高可用的關(guān)鍵技術(shù)發(fā)展與現(xiàn)狀，并結(jié)合天翼物聯(lián)基于PaaS架構(gòu)實(shí)現(xiàn)跨資源池應(yīng)用雙活高可用的實(shí)踐，提出一種跨資源池雙活高可用系統(tǒng)架構(gòu)以及一系列支撐組件，以期對(duì)電信業(yè)務(wù)高可用容災(zāi)與云網(wǎng)融合技術(shù)發(fā)展提供借鑒。

圖1 總體技術(shù)架構(gòu)

2 跨資源池高可用關(guān)鍵技術(shù)

2.1 技術(shù)方案現(xiàn)狀

業(yè)界常見(jiàn)的跨資源池高可用容災(zāi)架構(gòu)方案主要有“主備”、“多活”、“兩地三中心”，主備方案通過(guò)建設(shè)備份資源池，定期或?qū)崟r(shí)將主機(jī)房的數(shù)據(jù)備份到備用機(jī)房，在主機(jī)房發(fā)生故障時(shí)，保證數(shù)據(jù)在備機(jī)房可用可恢復(fù)，這種方案中，備用機(jī)房在主機(jī)房可用的情況下，不對(duì)外提供服務(wù)。此類(lèi)方案包括機(jī)房互備等變種方案，往往實(shí)現(xiàn)較為簡(jiǎn)單，成本可控，維護(hù)也較為容易，而且能夠應(yīng)對(duì)人為誤操作或系統(tǒng)邏輯錯(cuò)誤，但發(fā)生故障時(shí)，會(huì)存在數(shù)據(jù)丟失，恢復(fù)與切換時(shí)間長(zhǎng)的問(wèn)題。多活方案通過(guò)專用的一套多活組件和服務(wù)，確保各機(jī)房間服務(wù)、配置、數(shù)據(jù)的一致性，同時(shí)導(dǎo)入流量到多個(gè)機(jī)房，確保每一個(gè)機(jī)房任何時(shí)間都是正常工作的。當(dāng)發(fā)生機(jī)房級(jí)故障時(shí)，能夠做到流量在機(jī)房間的秒級(jí)切換，確保線上業(yè)務(wù)的穩(wěn)定性。兩地三中心是在同城雙中心的基礎(chǔ)上，增加災(zāi)備異地?cái)?shù)據(jù)中心，進(jìn)一步提升業(yè)務(wù)高可用容災(zāi)能力。

容災(zāi)關(guān)鍵指標(biāo)主要是（1）恢復(fù)時(shí)間目標(biāo)（Recovery Time Objective，RTO）表示了從災(zāi)難發(fā)生直到業(yè)務(wù)流程被恢復(fù)的時(shí)間；（2）恢復(fù)點(diǎn)目標(biāo)（Recovery Point Objective，RPO）是災(zāi)難發(fā)生后業(yè)務(wù)能夠容忍的數(shù)據(jù)丟失量，對(duì)于高可用容災(zāi)建設(shè)方案來(lái)說(shuō)，一般 RPO越高容災(zāi)的成本會(huì)越高，但故障造成業(yè)務(wù)的損失就越小。因此一般需要基于業(yè)務(wù)影響綜合評(píng)估，分析評(píng)估出業(yè)務(wù)中斷后對(duì)企業(yè)的影響（經(jīng)濟(jì)影響、非經(jīng)濟(jì)影響和客戶影響），明確業(yè)務(wù)的關(guān)鍵性及其RPO和RTO。

對(duì)于跨資源池高可用容災(zāi)方案來(lái)說(shuō)，本質(zhì)上是一個(gè)系統(tǒng)跨資源池分布式的問(wèn)題，也符合分布式CAP定理（如圖2所示），也就是可用性（如遠(yuǎn)程備份機(jī)房距離遠(yuǎn)1 000公里，容忍較大范圍自然災(zāi)害，同時(shí)響應(yīng)要快）、一致性（如數(shù)據(jù)零丟失）、分區(qū)容忍性（分布式系統(tǒng)必須要具備）無(wú)法全部選擇。因此跨資源池高可用容災(zāi)也是在CP和AP之間進(jìn)行取舍，根據(jù)業(yè)界實(shí)踐經(jīng)驗(yàn)，一般當(dāng)資源池機(jī)房之間網(wǎng)絡(luò)延時(shí)在較小的區(qū)間（如小于3 ms），能取得較好的平衡，但網(wǎng)絡(luò)延時(shí)達(dá)到一定程度后（如超過(guò)40 ms），會(huì)達(dá)到顯著的CA矛盾狀態(tài)，一般是通過(guò)放棄一定一致性來(lái)實(shí)現(xiàn)應(yīng)用系統(tǒng)的高可用。從多資源池高可用總體方案來(lái)說(shuō)，大致可以分為同城異址（近距離容災(zāi)）和遠(yuǎn)程異地（遠(yuǎn)距離容災(zāi)），同城異址的災(zāi)備中心可以有效應(yīng)對(duì)諸如停電、建筑物損壞、人為惡意破壞等能夠造成生產(chǎn)中心完全癱瘓的各類(lèi)風(fēng)險(xiǎn)，且當(dāng)兩地距離在一定的范圍內(nèi)（如30 KM內(nèi)）時(shí)可采用同步復(fù)制技術(shù)，從而達(dá)到非常小的RPO指標(biāo)要求。但近距離容災(zāi)無(wú)法防范大范圍災(zāi)難。選擇遠(yuǎn)程異地建設(shè)災(zāi)備中心可以應(yīng)對(duì)更大范圍的災(zāi)難，通常是由自然災(zāi)害如地震、海嘯、水災(zāi)等風(fēng)險(xiǎn)引發(fā)的重大災(zāi)難。但當(dāng)距離達(dá)一定范圍以上時(shí)，只能采用異步復(fù)制技術(shù)，災(zāi)難發(fā)生時(shí)有部分?jǐn)?shù)據(jù)損失，需要采取其它輔助手段進(jìn)行損失數(shù)據(jù)的恢復(fù)，來(lái)保障數(shù)據(jù)的完整性和一致性。對(duì)比情況如表1所示。

圖2 CAP原理圖

表1 同城異址與遠(yuǎn)程異地對(duì)比

2.2 關(guān)鍵技術(shù)分析

由于系統(tǒng)分布在多個(gè)資源池機(jī)房之上，要保障應(yīng)用系統(tǒng)容災(zāi)高可用，有一些列的關(guān)鍵問(wèn)題需要解決。在數(shù)據(jù)層面，關(guān)鍵問(wèn)題包括：數(shù)據(jù)復(fù)制、數(shù)據(jù)兜底修復(fù)、數(shù)據(jù)備份恢復(fù)；在基礎(chǔ)支撐層面，關(guān)鍵問(wèn)題包括：高可靠低延時(shí)網(wǎng)絡(luò)、流量路由分發(fā)、全局協(xié)調(diào)與感知、多資源池部署支持。

2.2.1 數(shù)據(jù)面技術(shù)

（1）數(shù)據(jù)復(fù)制

當(dāng)系統(tǒng)跨資源池部署運(yùn)行，數(shù)據(jù)層使用了分布式存儲(chǔ)結(jié)構(gòu)后，為了保障數(shù)據(jù)可靠，數(shù)據(jù)會(huì)在多個(gè)資源池同時(shí)存在，數(shù)據(jù)的變更如何在不同資源池保持一致是跨資源池需要處理的核心問(wèn)題，而一致性的強(qiáng)弱對(duì)整個(gè)多資源池高可用架構(gòu)又會(huì)產(chǎn)生重大的影響。針對(duì)一致性問(wèn)題主要的技術(shù)解決方案有：

（a）基于應(yīng)用的復(fù)制

基于應(yīng)用復(fù)制的容災(zāi)備份技術(shù)是在應(yīng)用軟件層面實(shí)現(xiàn)數(shù)據(jù)的復(fù)制和同步，由應(yīng)用程序的代碼邏輯完成數(shù)據(jù)復(fù)制，可以分為同步和異步兩種方式，從實(shí)現(xiàn)上可以分為二次提交和LOG復(fù)制。

（b）基于數(shù)據(jù)庫(kù)組件的多副本復(fù)制機(jī)制實(shí)現(xiàn)

將數(shù)據(jù)庫(kù)主備服務(wù)部署在不同的資源池，通過(guò)組件自身的數(shù)據(jù)同步來(lái)實(shí)現(xiàn)高可用。由于復(fù)制會(huì)給數(shù)據(jù)的存取操作帶來(lái)影響，此種方案對(duì)網(wǎng)絡(luò)延時(shí)有一定的前置要求，否則對(duì)業(yè)務(wù)操作的響應(yīng)時(shí)間會(huì)有不可接受的影響。在出現(xiàn)故障時(shí)，組件自動(dòng)切換主節(jié)點(diǎn)，恢復(fù)數(shù)據(jù)可用性。常見(jiàn)的有Mysql主從復(fù)制，Oracle DataGuard 等。

（c）基于數(shù)據(jù)同步復(fù)制組件實(shí)現(xiàn)

在不同資源池均部署獨(dú)立的數(shù)據(jù)庫(kù)集群，數(shù)據(jù)庫(kù)之間同步單獨(dú)的數(shù)據(jù)同步組件來(lái)實(shí)現(xiàn)數(shù)據(jù)復(fù)制（如Oracle GoldenGate、中國(guó)電信集團(tuán)自研的跨IDC數(shù)據(jù)同步組件、開(kāi)源組件Otter、Canal等），這種組件由于無(wú)法介入數(shù)據(jù)庫(kù)事務(wù)，因此無(wú)法實(shí)現(xiàn)強(qiáng)一致性，出現(xiàn)故障時(shí)，需要選擇犧牲一定的一致性?；ヂ?lián)網(wǎng)行業(yè)常見(jiàn)優(yōu)化實(shí)現(xiàn)方案是業(yè)務(wù)分區(qū)，如正常情況蘇州用戶訪問(wèn)資源池A，非蘇州用戶訪問(wèn)資源池B，保持請(qǐng)求在單個(gè)資源池內(nèi)完成（需要業(yè)務(wù)系統(tǒng)具備相關(guān)條件），數(shù)據(jù)保持一致。同時(shí)數(shù)據(jù)按照分區(qū)雙向同步，保證數(shù)據(jù)實(shí)時(shí)同步。在出現(xiàn)故障時(shí)，可以選擇立即切換恢復(fù)業(yè)務(wù)（小部分不一致性由業(yè)務(wù)發(fā)現(xiàn)并補(bǔ)償處理），需要稽核與業(yè)務(wù)兜底工具。對(duì)于雙向同步的問(wèn)題解決方案有：

① 順序保證：通過(guò)有序隊(duì)列來(lái)保存數(shù)據(jù)變更事件，按順序定位并拉取Event；

② 寫(xiě)入沖突處理：通過(guò)不同的序列避免主鍵沖突（如機(jī)房A使用奇數(shù)，機(jī)房B使用偶數(shù)），如發(fā)生沖突，通過(guò)時(shí)間戳進(jìn)行沖突判斷，可支持調(diào)用業(yè)務(wù)提供hook來(lái)解決；

③ 循環(huán)復(fù)制處理：通過(guò)在復(fù)制事務(wù)中加入HackSQL或其他標(biāo)記，記錄數(shù)據(jù)來(lái)源，當(dāng)檢測(cè)到數(shù)據(jù)來(lái)源為當(dāng)前需要同步的目標(biāo)節(jié)點(diǎn)，則跳過(guò)同步。

（d）基于主機(jī)的數(shù)據(jù)復(fù)制技術(shù)

基于主機(jī)的數(shù)據(jù)復(fù)制技術(shù)是通過(guò)主機(jī)上磁盤(pán)卷的復(fù)制或者鏡像來(lái)實(shí)現(xiàn)，在主節(jié)點(diǎn)數(shù)據(jù)被破壞時(shí)，可以從備份節(jié)點(diǎn)恢復(fù)數(shù)據(jù)與應(yīng)用。由于主機(jī)的系統(tǒng)一般對(duì)底層硬件有一定的抽象，因此對(duì)存儲(chǔ)設(shè)備限制較小，但是會(huì)占用一定比例的主機(jī)資源，對(duì)性能有一定影響。

（e）基于存儲(chǔ)網(wǎng)關(guān)的數(shù)據(jù)復(fù)制實(shí)現(xiàn)

基于存儲(chǔ)網(wǎng)關(guān)的數(shù)據(jù)復(fù)制在服務(wù)器與存儲(chǔ)之間的網(wǎng)關(guān)側(cè)捕獲數(shù)據(jù)流，利用存儲(chǔ)網(wǎng)關(guān)對(duì)于后端存儲(chǔ)的數(shù)據(jù)進(jìn)行遠(yuǎn)程數(shù)據(jù)復(fù)制，可以支持異構(gòu)存儲(chǔ)融合、存儲(chǔ)設(shè)備高可用鏡像、快照服務(wù)、數(shù)據(jù)遷移服務(wù)甚至于部分存儲(chǔ)網(wǎng)關(guān)可以提供精準(zhǔn)的持續(xù)數(shù)據(jù)保護(hù)連續(xù)數(shù)據(jù)恢復(fù)服務(wù)。

（f）基于存儲(chǔ)介質(zhì)的數(shù)據(jù)復(fù)制實(shí)現(xiàn)

通過(guò)存儲(chǔ)系統(tǒng)中的軟硬件將數(shù)據(jù)通過(guò)網(wǎng)絡(luò)通道以同步或者異步的方式復(fù)制到遠(yuǎn)端設(shè)備。這種技術(shù)一般對(duì)存儲(chǔ)系統(tǒng)的型號(hào)有一定的要求，對(duì)低延遲高帶寬網(wǎng)絡(luò)也有一定的要求。

（2）數(shù)據(jù)兜底修復(fù)

當(dāng)跨資源池使用最終一致性方式來(lái)實(shí)現(xiàn)，在切換時(shí)有數(shù)據(jù)寫(xiě)入，則可能導(dǎo)致數(shù)據(jù)出現(xiàn)不一致的情況（如部分表數(shù)據(jù)未同步完成），如果對(duì)這部分?jǐn)?shù)據(jù)進(jìn)行檢測(cè)與修復(fù)是一個(gè)難點(diǎn)問(wèn)題。由于此問(wèn)題與業(yè)務(wù)關(guān)聯(lián)緊密，目前沒(méi)有通用的解決方案，主要解決思路有：

（a）數(shù)據(jù)同步組件發(fā)現(xiàn)新數(shù)據(jù)的時(shí)間戳早于現(xiàn)有數(shù)據(jù)的情況時(shí)，進(jìn)行異常記錄，記錄數(shù)據(jù)庫(kù)事件詳細(xì)信息，支持通過(guò)工具生成反向操作，對(duì)沖錯(cuò)誤的數(shù)據(jù)操作；

（b）業(yè)務(wù)數(shù)據(jù)如果有明顯的狀態(tài)遷移順序，可以根據(jù)狀態(tài)機(jī)進(jìn)行修復(fù)；

（c）當(dāng)數(shù)據(jù)變更歷史過(guò)多，次序不清，數(shù)據(jù)很難修復(fù)時(shí)，可以業(yè)務(wù)重做，重置業(yè)務(wù)狀態(tài)；

（d）考慮到損失的部分一般概率和數(shù)據(jù)量非常小，對(duì)于可用性優(yōu)先的系統(tǒng)，可以先對(duì)外提供服務(wù)，但是對(duì)于異常數(shù)據(jù)的部分用戶，需要停止數(shù)據(jù)的修改，避免數(shù)據(jù)沖突不一致后難以恢復(fù)。

（3）數(shù)據(jù)備份恢復(fù)

當(dāng)在線服務(wù)數(shù)據(jù)異常，尤其是當(dāng)多個(gè)副本數(shù)據(jù)因?yàn)檎`操作等原因全部損壞的情況下，需要通過(guò)備份的數(shù)據(jù)，恢復(fù)數(shù)據(jù)到最新一次的可用狀態(tài)。數(shù)據(jù)備份常見(jiàn)的方案有：

（a）基于數(shù)據(jù)庫(kù)組件的機(jī)制：大部分的數(shù)據(jù)庫(kù)組件（如mysql、redis、ctgmq，nexus，gitlab）均需要使用對(duì)應(yīng)的工具對(duì)數(shù)據(jù)進(jìn)行備份與恢復(fù)，無(wú)法直接讀取備份的磁盤(pán)文件。如中國(guó)電信集團(tuán)分布式數(shù)據(jù)庫(kù)備份恢復(fù)使用udaldump（底層為xtrabackup）；

（b）存儲(chǔ)備份恢復(fù)：部分?jǐn)?shù)據(jù)庫(kù)存儲(chǔ)能夠使用備份操作系統(tǒng)文件或磁盤(pán)設(shè)備的方式進(jìn)行，如容器運(yùn)行的mysql、redis等。常用的備份實(shí)現(xiàn)方式為rsync、cron腳本、商用備份軟件，CDP（Continuous Data Protection連續(xù)數(shù)據(jù)保護(hù)）、CDM（Copy Data Management數(shù)據(jù)副本管理）等。

2.2.2 基礎(chǔ)支撐面技術(shù)

（a）高可靠低延時(shí)網(wǎng)絡(luò)

資源池之間的網(wǎng)絡(luò)是跨資源池高可用容災(zāi)方案的關(guān)鍵模塊。網(wǎng)絡(luò)延時(shí)越高，應(yīng)用需要做高可用與一致性取舍的難度也隨之提高。網(wǎng)絡(luò)要求主要體現(xiàn)在：（1）網(wǎng)絡(luò)高可靠，雙路冗余網(wǎng)絡(luò)接入，網(wǎng)絡(luò)故障自動(dòng)切換；（2）對(duì)于要求數(shù)據(jù)零丟失（RPO=0）的場(chǎng)景，數(shù)據(jù)庫(kù)需要配置為同步模式，為避免對(duì)業(yè)務(wù)響應(yīng)的影響，網(wǎng)絡(luò)延時(shí)要求RTT小于3 ms；（3）現(xiàn)有teledb等組件依賴keepalived來(lái)實(shí)現(xiàn)高可用，由于keepalived基于vrrp實(shí)現(xiàn)，vrrp是一個(gè)工作在網(wǎng)絡(luò)二層協(xié)議，因此需要具備二層網(wǎng)絡(luò)支持，常見(jiàn)解決方案有裸光纖、三層專線和二層專線等。

（b）流量路由分發(fā)

在雙活/多活架構(gòu)下，流量需要根據(jù)系統(tǒng)升級(jí)計(jì)劃中的步驟進(jìn)行細(xì)粒度的控制，因此需要一個(gè)入口流量控制的模塊來(lái)實(shí)現(xiàn)（1）流量分發(fā)，根據(jù)相應(yīng)規(guī)則分發(fā)流量到后端服務(wù)；（2）批量配置與切換，支持為請(qǐng)求打上多資源池標(biāo)簽，決定路由到哪個(gè)機(jī)房；（3）提供開(kāi)放API，由外部統(tǒng)一進(jìn)行網(wǎng)關(guān)的控制與操作。常見(jiàn)的解決方案有NetScaler、F5、Radware和Array等硬件負(fù)載均衡以及haproxy、nginx和lvs等軟件負(fù)載均衡方式。

（c）網(wǎng)絡(luò)切換

在執(zhí)行流量分擔(dān)、故障演練、或者實(shí)際發(fā)生故障切換時(shí)，需要對(duì)應(yīng)用系統(tǒng)的請(qǐng)求網(wǎng)絡(luò)進(jìn)行切換。常見(jiàn)的解決方案有：基于浮動(dòng)IP地址切換、基于DNS切換、基于四層交換機(jī)切換、基于應(yīng)用切換。

（d）全局協(xié)調(diào)與感知

系統(tǒng)使用PaaS組件上云后，一般會(huì)用到多個(gè)組件，容災(zāi)切換需要多組件一起配合完成，需要系統(tǒng)具備1）統(tǒng)一、一致的雙活邏輯；2）發(fā)生組件切換時(shí)，執(zhí)行特定邏輯、發(fā)出通知、觸發(fā)動(dòng)作。此需求一般為特定方案特定實(shí)現(xiàn)如采用軟件方式，如實(shí)現(xiàn)容災(zāi)任務(wù)編排或公共的全局協(xié)調(diào)模塊。

（e）多資源池部署支持

在應(yīng)用系統(tǒng)多資源池同時(shí)運(yùn)行的架構(gòu)下，應(yīng)用和服務(wù)的部署、發(fā)布與變更需要在多個(gè)資源池重復(fù)操作，容易出現(xiàn)版本、配置不一致，操作時(shí)間長(zhǎng)，遷移效率低等問(wèn)題。此需求常用的技術(shù)有：基于集群聯(lián)邦技術(shù)實(shí)現(xiàn)，或基于已有部署API，構(gòu)建多資源池部署管理層能力，實(shí)現(xiàn)應(yīng)用的定義與管理控制。

3 雙活高可用方案與實(shí)踐成果

3.1 方案設(shè)計(jì)

（1）技術(shù)方案

方案遵循充分利用已有成熟能力、可用性優(yōu)先、盡量減少業(yè)務(wù)改造量、保障數(shù)據(jù)正確性以及業(yè)務(wù)可感知的設(shè)計(jì)原則，整體上采用分層解耦高可用的方式來(lái)實(shí)現(xiàn)，保持每一層的靈活可用，實(shí)現(xiàn)應(yīng)用級(jí)的容災(zāi)。

整體方案架構(gòu)如圖3所示。

圖3 總體方案示意圖

（a）負(fù)載路由層

該層提供各應(yīng)用統(tǒng)一入口，提供入口流量控制能力，根據(jù)分發(fā)規(guī)則將業(yè)務(wù)流量分發(fā)至多個(gè)資源池應(yīng)用；流量分發(fā)至應(yīng)用通過(guò)3層網(wǎng)絡(luò)交互。通過(guò)流量路由分發(fā)模塊，實(shí)現(xiàn)入口流量控制。

（b）應(yīng)用服務(wù)層

應(yīng)用在兩個(gè)機(jī)房各部署1套相同版本應(yīng)用，應(yīng)用可以部署到虛擬機(jī)或容器中運(yùn)行；應(yīng)用訪問(wèn)PaaS組件通過(guò)3層網(wǎng)絡(luò)交互；通過(guò)多資源池部署模塊，基于OpenApplicationModel[15]模型接口，實(shí)現(xiàn)應(yīng)用跨資源池部署、升級(jí)、管理，應(yīng)用1次發(fā)布，同時(shí)部署到多資源池中的虛擬機(jī)或容器中；應(yīng)用部署到容器中，基于容器、集群技術(shù)，實(shí)現(xiàn)應(yīng)用層無(wú)狀態(tài)多副本運(yùn)行。

（c）PaaS組件層

選用中國(guó)電信集團(tuán)3個(gè)A類(lèi)PaaS組件：Teledb、分布式消息、分布式緩存，基于各組件自身多副本復(fù)制機(jī)制實(shí)現(xiàn)數(shù)據(jù)同步復(fù)制，保障數(shù)據(jù)一致性，和各組件自身的高可用機(jī)制，實(shí)現(xiàn)主從切換，保障組件可用性。

Teledb：Mysql部署1主3從，2個(gè)機(jī)房各2個(gè)Mysql實(shí)例；主從數(shù)據(jù)同步，基于2層網(wǎng)絡(luò)（專線）進(jìn)行數(shù)據(jù)同步，保證數(shù)據(jù)同步性能，同時(shí)滿足Teledb 的keepalive組件vrrp通信協(xié)議（2層）要求，實(shí)現(xiàn)VIP漂移對(duì)應(yīng)用提供統(tǒng)一數(shù)據(jù)庫(kù)入口。

分布式消息：Broker部署2主2從，2個(gè)機(jī)房各2個(gè)broker實(shí)例；主從數(shù)據(jù)同步，基于3層網(wǎng)絡(luò)進(jìn)行數(shù)據(jù)同步。

分布式緩存：1對(duì)Redis主從服務(wù)器+2臺(tái)切換空機(jī)，兩個(gè)機(jī)房各1臺(tái)Redis+1臺(tái)切換空機(jī)；Redis數(shù)據(jù)同步，基于3層網(wǎng)絡(luò)進(jìn)行數(shù)據(jù)同步。

ZK公共組件通過(guò)第三資源池節(jié)點(diǎn)作為協(xié)調(diào)可用區(qū)，保障集群奇數(shù)實(shí)例，任意資源池故障時(shí)高可用；PaaS各組件與對(duì)應(yīng)組件管理平臺(tái)互通基于3層網(wǎng)絡(luò)進(jìn)行交互。

（d）基礎(chǔ)設(shè)施層

在資源池間建設(shè)一對(duì)萬(wàn)兆鏈路以mclag主備保護(hù)，組件主從同步通過(guò)新增的資源池直連鏈路互訪；其他延遲要求不高的應(yīng)用均從B平面網(wǎng)絡(luò)互通。各資源池與城域網(wǎng)B平面新增建設(shè)一條三層vpn鏈路，放通DNS/API router/組件管理平臺(tái)/管理服務(wù)/app應(yīng)用/zk組件/分布式消息中間件/分布式緩存組件網(wǎng)絡(luò)，使各組件實(shí)現(xiàn)互通；同時(shí)對(duì)Teledb等組件網(wǎng)絡(luò)以負(fù)載分擔(dān)方式新增建設(shè)一對(duì)B平面三層vpn鏈路分別指向資源池節(jié)點(diǎn)，用以實(shí)現(xiàn)網(wǎng)絡(luò)冗余。

（2）關(guān)鍵技術(shù)應(yīng)用

對(duì)應(yīng)2.2關(guān)鍵技術(shù)分析章節(jié)中的關(guān)鍵問(wèn)題，技術(shù)方案匯總?cè)绫?所示。

表2 方案關(guān)鍵技術(shù)應(yīng)用

3.2 實(shí)踐驗(yàn)證

（1）驗(yàn)證環(huán)境

實(shí)驗(yàn)選取蘇州A、B兩個(gè)資源池進(jìn)行部署測(cè)試，專線網(wǎng)絡(luò)建設(shè)后，網(wǎng)絡(luò)延時(shí)保持在2 ms以內(nèi)，項(xiàng)目涉及的應(yīng)用組件及高可用組件等均部署在服務(wù)器虛擬化集群和容器集群上，共計(jì)使用資源248核CPU、936G內(nèi)存、1.95T內(nèi)存。

（2）驗(yàn)證方法

實(shí)驗(yàn)從兩個(gè)層面對(duì)方案進(jìn)行驗(yàn)證，分別是PaaS層組件單獨(dú)容災(zāi)驗(yàn)證，以及基于試點(diǎn)應(yīng)用的整體容災(zāi)驗(yàn)證。驗(yàn)證工具包括jmeter、自開(kāi)發(fā)的模擬請(qǐng)求程序以及數(shù)據(jù)比對(duì)程序。驗(yàn)證步驟為：

（A）檢查服務(wù)狀態(tài)

（B）開(kāi)啟請(qǐng)求模擬工具，對(duì)組件或應(yīng)用進(jìn)行模擬訪問(wèn)

（C）通過(guò)關(guān)閉服務(wù)器、修復(fù)網(wǎng)絡(luò)策略、設(shè)置防火墻、殺掉進(jìn)程、網(wǎng)絡(luò)阻斷的方式模擬故障

（D）過(guò)程中持續(xù)觀察請(qǐng)求端響應(yīng)狀態(tài)

（E）記錄組件服務(wù)狀態(tài)、異常恢復(fù)時(shí)間等結(jié)果數(shù)據(jù)

（3）驗(yàn)證結(jié)果

實(shí)驗(yàn)結(jié)果表明方案達(dá)到跨資源池高可用容災(zāi)切換預(yù)期（RTO小于15分鐘，同步RPO等于0）。詳細(xì)測(cè)試驗(yàn)證場(chǎng)景與結(jié)果如表3所示。

表3 測(cè)試驗(yàn)證場(chǎng)景與結(jié)果

4 結(jié)束語(yǔ)

隨著分布式架構(gòu)的普及，核心業(yè)務(wù)系統(tǒng)架構(gòu)日趨復(fù)雜，為業(yè)務(wù)系統(tǒng)提供跨資源池高可用的服務(wù)能力是技術(shù)底座或云平臺(tái)的關(guān)鍵需求。本文針對(duì)電信內(nèi)部業(yè)務(wù)系統(tǒng)的跨資源池高可用需求，對(duì)相關(guān)云網(wǎng)關(guān)鍵技術(shù)進(jìn)行了研究，并基于蘇州A、B兩個(gè)資源池進(jìn)行了技術(shù)方案設(shè)計(jì)與實(shí)踐驗(yàn)證，對(duì)跨資源池的PaaS組件高可用、專線網(wǎng)絡(luò)支持、流量路由、容災(zāi)切換等方面的技術(shù)進(jìn)行了探索，提出并實(shí)現(xiàn)了一種跨資源池高可用雙活系統(tǒng)架構(gòu)以及一系列支撐組件與平臺(tái)，希望對(duì)電信核心系統(tǒng)的高可用連續(xù)性解決方案以及云網(wǎng)技術(shù)融合發(fā)展提供一定的借鑒意義。