如何讓服務可用性高達99.9999%？異地災備是關鍵！

爲了保障業務系統在遭受意外的狀況下依然可以正常運轉，企業每每會在異地部署一套與現有的業務系統同樣的生產環境，即異地災備系統。它能夠保障業務安全和穩定，有效提升業務系統抵抗外界因素的容災能力。

（文末附視頻版講解及完整資料下載）

01

概念和方案 

Share78容災國際標準定義了7個災備層級。

0級：沒有異地可恢復數據

1級：介質異地備份

2級：介質異地存儲加熱備份站點

3級：用電子鏈路實現數據備份

4級：定時數據備份

5級：備份站點保持運轉

6級：零數據丟失

RPO和RTO

RPO和RTO是衡量容災系統的兩個主要指標。RPO是Recovery Point Objective，恢復點目標，是指災難發生後業務能容許的數據丟失量。下圖所示是關於數據損失和成本的權衡。顯然，數據損失這條線和成本這條線是反相關的：想將數據損失降到越低，付出的成本也會越高。圖中的相交點表明合理折中的實現度的所在位置。實現一個簡單的備份成本很低，效果可能也不是很理想，但也比沒有好。另外，咱們也不宜爲了減小數據損失而付出過大的成本支出，因此找到圖中這個相交的點是貫穿全部方案的中心思考。 

RTO是Recovery Time Objective，恢復時間目標，是指從災難發生到業務恢復的時間。好比，當電腦系統死機時，而咱們急着用電腦，那麼不管數據是否須要恢復，能夠暫時先換一臺備用電腦，這種狀況下的RTO爲零。可是，若是咱們不着急用，接着花了一小時來恢復數據，那麼RTO爲一小時。RTO和成本的關係如圖所示，和RPO同樣也是反相關的。要求數據恢復時間越短，實現的成本代價就越高。咱們設計方案一樣也要尋找恢復時間和成本的折中點。 

容災技術方案類型

容災技術方案通常有四類。第一類是同城容災，指在較近的距離建設同城機房，通常距離在200km內，這樣通訊的質量好、時延小。若是網絡足夠好甚至能夠視爲一個本地機房使用，此時數據的備份方案更加簡單、易實現，好比採用同步方式，在必定程度上可以防範損失。

第二類是異地容災，這是相對同城而言的。面對範圍較大的災害，好比地震、水災或者大規模網絡故障等，同城機房可能遭遇同時不可用的狀態。反之異地容災的缺點也很明顯，時延更高，不適用同步備份。

第三類是兩地三中心模式。兩地是指同城、異地；三中心是指生產中心、同城容災中心、異地容災中心。這是前面兩種容災技術方案的結合，具有前二者的優勢，但成本也會更高，通常應用於金融行業。

第四類是「雙活」或 「多活」模式，區別於傳統數據中心和災備中心的模式。傳統模式下，生產數據中心投入運行，災備數據中心處在不工做狀態，只有當災難發生時，生產數據中心癱瘓，災備中心才啓動。而在「雙活」和「多活」模式下，存在兩個甚至多個數據中心同時處於運行的狀況。在這兩種模式下，它們運行相同的應用、具有一樣的數據，可以提供跨中心業務負載均衡運行，具有持續的應用可用性和災難備份能力。 

02

異地災備建設歷程 

v1.0

個推的災備建設始於2015年。其最初緣由是業務壯大後致使原機房資源接近飽和。當初咱們使用的是運營商機房，因爲機房容量限制和內部網絡壓力，咱們開始準備再建一個機房，在方案設計上考慮必定程度的災備。

結合當時的業務情況和難點進行分析，主要存在三點問題：

 

1、因爲推送的⻓鏈接特性，切換服務時會斷開鏈接，下發效果易受到影響；

2、數據源多樣，好比REDIS、CODIS、ELASTICSEARCH、MYSQL，每種組件都須要數據同步並保證一致性；

3、服務依賴多，各服務模塊互相之間依賴、服務模塊與中間件相依賴。

個推異地災備1.0架構方案是數據按帳號維度分機房存儲，主要業務仍然在各自歸屬機房內完成，這樣資源壓力就獲得了分攤。有須要的狀況下，各業務模塊可根據帳號路由請求到其它機房，中間經過一個轉發模塊，將各模塊業務中須要跨機房的請求進行包裝加密，經過公網和專線兩種路徑進行請求轉發。 

架構v1.0存在如下問題：

1、 業務模塊耦合了大量跨機房轉發邏輯，甚至各模塊已經內含不一樣的跨機房業務邏輯，負責接手的開發人員須要熟悉相應的邏輯，增長了修改維護的人力成本。

2、擴展性有待提高。現有架構並未設計數據熱遷移的方案，若是再建機房則須要作修改。

v1.5 

新的架構需求的出發點在於，個推計劃建設一個新的機房作數據熱備，支持帳號機房歸屬的快速切換，以及過大的數據集羣(Redis、ElasticSearch)也須要拆分管理。出於業務須要，咱們產出了一個過渡的1.5架構。

在該架構中，MySQL和文件直接使用Otter來作數據同步。它支持一些插件進行任務處理，好比協助與表字段相關的文件傳輸。其他組件，如ElasticSearch、Redis、Codis裏面的數據結構，暫時仍是經過模塊的業務請求記錄日誌，經過Flume寫到RocketMQ，而後由另外一個IDC的同步工具消費回放請求。mq會部署在日誌生成的當前機房，這樣數據的可靠性更有保障，不會因網絡問題堵住生產者。爲了保障數據的順序，咱們根據業務將註冊請求優先實時同步，其它請求滯後非實時同步，必定程度上保障了業務數據的順序性。

咱們通過深刻調研，最終選用了Otter。它的主要結構包括Node和Manager兩大塊，Manager負責配置管理，有 Web⻚面支持；Node是實際工做節點，而且內嵌有一個Cannal，也支持接入獨立部署的Cannal實例。 

整個同步流程抽象爲Select、Extract、Transform、Load4個階段。

在本地機房進行兩個階段（S、E）

● Select階段: 爲解決數據來源的差別性，好比接入canal獲取增量數據，也能夠接入其餘系統獲取其餘數據等。

●  Extract階段: 組裝數據，針對多種數據來源，好比mysql、oracle、store、file等，進行數據組裝和過濾，這裏能夠加入自定義的解析代碼，包括文件處理FileRElasticSearcholver。

在異地機房進行兩個階段（T、L）

● Transform階段: 數據提取轉換過程，把數據轉換成目標數據源要求的類型。

●  Load階段: 數據載入，將數據載入到目標端。

這個方案存在如下優勢：

1、數據同步上業務的耦合度也降低了不少，數據層面改動較少，除少許配合otter同步對不一樣機房db中主鍵ID的惟一性進行了修復，其它的組件都是外部增長的；

2、⻛險更可控，業務開發更容易理解和維護，之後想增長機房或者數據同步種類都比較方便。

架構v1.5的不足在於：

數據清理、維護分開處理，這過程當中可能會產生不一致性。

v2.0

在1.5投入運行後，咱們繼續規劃實現了2.0架構。該架構主要變動了數據同步形式，從經過日誌傳輸請求回放，替換爲所有經過數據組件底層工具進行同步，主要經過業務和數據中間的網關代理實現負載路由以及同步管理。除了1.5已經處理的MySQL同步外，其它的如ElasticSearch、Redis、Codis都用了這套代理模式。 

ElasticSearch的數據同步是個推本身構建的方案。這個方案中，全部的請求在通過Proxy時都會根據必定策略路由到目標集羣，實現了多集羣的拆分和管理。進行備份或者遷移的步驟爲：首先，準備好備份或者遷移的目標集羣（同機房或異地機房），更新配置註冊到Proxy上；第二步，對老集羣的源數據全量導出到kafka，同時開啓增量雙寫，進入Proxy的請求，若是是要備份的部分，也同時寫入kafka中。這樣數據在兩個集羣就造成了熱備。故只須要切換路由，就可以實現切換到另外一個機房的集羣，備份的集羣就徹底能夠提供服務了。

關於Redis和Codis的數據同步，咱們調研了兩種開源方案，攜程的XPipe和Redis-replicator，二者都不能徹底知足需求，但其部分理念可被參考，爲此，咱們最終設計了以下的整體結構圖。

咱們利用了Redis的主從同步機制，Keeper做爲一個從⻆色將主節點同步過來的數據，經過傳輸通道寫到備份集羣。

其中，Keeper是數據同步組件，有兩種⻆色，一是做爲Redis的從節點，二是將數據寫入備份的IDC，Keeper的組件由manager管理，傳輸通道能夠直接tcp傳輸，或者依賴消息隊列。IDC故障須要切換時，故障機房的數據層自己不須要作什麼操做，只要機房歸屬的路由切換過來便可。

這個方案的優勢在於，在處理業務邏輯時不用考慮多機房同步的相關問題。網關層能夠集中實現全部須要的功能，如備份策略、負載策略、調度策略、監控、隔離、權限等等。美中不足的是必定程度上增長了網關層的開發和維護成本。

03

總結和展望

企業要想爲用戶提供穩定的保障服務，容災工做必定要作到位。咱們沒法預見線上環境何時會出現問題，通常來說，尤爲是當集羣規模比較大的狀況下，小事故是很是高頻的。固然容災也要結合成本的考量，選擇適合業務發展狀況的架構方案，想要一開始就設計出很是完美但費錢的方案只會拖垮業務。所以，個推的容災方案就是根據業務發展一步步迭代進行的。

除考慮自身業務外，企業在進行異地災備建設時還應深入洞悉行業發展趨勢：

採用多地多活，加快業務恢復速度；將服務虛擬化，使災備能夠更靈活地調配資源；實現業務連續性管理。

個推做爲異地災備領域的長期實踐者，也將持續探索災備理念，不斷打磨技術，與開發者一同分享異地災備系統建設的最新思路及方法。

完整版分享材料獲取

關注【個推技術學院】微信公衆號

（微信號：getuitech）

回覆關鍵詞「推送」

便可領取異地災備完整版分享材料！ 

此外，經過視頻連接還可觀看本文配套解析：

http://live.vhall.com/649915969