1 容災介紹
我們通常會把故障分為三大類，一是主機故障，二是機房故障，三是地域故障。每類故障都有各自的誘發因素，而從主機到機房再到地域，故障發生機率依次越來越小，而故障的影響卻越來越大。
容災能力的建設目标是非常明确的，就是要能夠應對和處理這種機房級和地域級的大規模故障，進而來保障業務的連續性。近幾年，業界也發生了多次資料中心級别的故障，對相關公司的業務和品牌産生了非常大的負面影響。目前容災能力已經成為衆多IT企業建設資訊化系統的必選項。
2 業務容災架構
| 2.1 容災架構演進
容災架構從最早期的單活形态（同城主備）到同城多活形态，再演化到異地多活，根據這個路徑可以将容災分為容災1.0、容災2.0、容災3.0三個階段。
- 容災1.0：容災體系圍繞資料建設，多以主-備的方式部署，但備用機房不承擔流量，基本上都是單活結構。
- 容災2.0：容災視角從資料轉換為應用系統，業務具有同城雙活或同城多活能力，采用同城雙活或同城雙活加異地冷備（兩地三中心）的部署架構，除冷備以外的每個機房都有流量處理能力。
- 容災3.0：以業務為中心，多采用單元化架構，容災基于單元間的兩兩互備實作，根據單元的部署位置可以實作同城多活和異地多活。采用單元化架構的應用本身具有很好的容災能力和擴充能力。
由于各公司所處發展階段不同，采用的方案也會有所差別，美團大部分業務處于2.0階段（即同城雙活或多活架構），但對于大體量、有地域容災及有地域擴充性要求的業務則處在容災3.0階段。下面會介紹一下美團的容災架構。
| 2.2 美團容災架構
美團的容災架構主要包括兩種，一種是N+1容災架構，一種是SET化架構。
N+1架構：在業界也稱散部或者多AZ部署⽅案，将容量為C的系統部署在N+1個機房，每個機房能提供至少C/N的容量，挂掉任何一個機房時，剩餘系統仍能支撐C的容量。該方案的核心是把容災能力下沉到PaaS元件來完成，在出現機房級或者地域級故障的時候，由各個PaaS元件獨立完成容災切換，實作業務恢複。整體架構如下圖所示，業務上表現是多機房、多活形态，資料庫采用這種主從架構，單機房處理寫流量、多機房的負載均攤讀流量。下面要講“資料庫容災體系建設實踐” 就是面向N+1架構的。
單元化架構：也叫SET化架構，這是一種偏應用層的容災架構，它将應用，資料，基礎元件按照統一的次元切分成多個單元，每個單元處理一部分閉環流量。業務以單元作為部署機關，通過單元互備方式實作同城容災或者異地容災。一般金融業務或者超大規模的業務會選擇此類架構，它的好處就是流量可以閉環且資源隔離，具有很強的容災能力和跨域擴充能力，不過SET化架構的落地需要業務系統做大量的改造，運維管理也較為複雜。簡化示意圖如下：
美團内部的大部分業務都是N+1架構，外賣和金融等業務采用了單元化架構。總體上美團内部既有同城多活，也有異地多活，兩種容災方案并存。
3 資料庫容災建設
| 3.1 面臨的挑戰
超大規模的叢集帶來的挑戰：公司業務高速發展，伺服器規模指數級增⻓，資料中心規模越來越大，大機房已有大幾千資料庫叢集，上萬個執行個體。
- 性能問題：高可用系統的故障并發處理能力出現明顯瓶頸。
- 容災失效風險：管控鍊路随叢集數量的增加變的越來越複雜，一個環節出問題就會導緻整體容災能力失效。
- 故障頻發：叢集數量和規模變大，使原來機率很低的大規模故障變成了稀松平常的故障，其發生的頻次和機率越來越高。
演練成本高、頻次低：核心能力驗證不充分，大規模故障的應對能力處于不可知狀态，已知容災能力“保鮮”困難。拿應對機房級大規模故障的相關能力來講，很大一部分是處于不可知狀态或者僅存在于“紙面”分析中，而對于已驗證過的能力随着架構演進疊代，“保鮮”也很困難。
資料庫作為有狀态的服務之一，本身建設應對大規模故障能力的難度和挑戰都相對更大。
| 3.2 基礎高可用
資料庫架構 在美團主要有兩種一種是主從架構，一種是MGR架構。
- 主從架構：應用通過資料庫中間件通路資料庫，在故障發生時，高可用做故障探測、拓撲調整、配置下發，進而應用恢複。
- MGR架構：應用也是通過中間件通路資料庫，不過中間件對MGR做了适配，内部叫Zebra for MGR，中間件自動進行拓撲探測感覺，一旦MGR發生了切換，新拓撲會被探測到，資料源會進行調整，進而業務恢複。
- 美團的高可用架構：美團主從叢集的高可用是基于Orchestrator二次開發的，本質上是一個中心化的管控架構，如下圖所示，有多個高可用分組，每個分組托管一部分資料庫叢集，分組在北京和上海實作兩Region部署，底層核心元件隻在北京部署，比如我們的核心CMBD、WorkflowDB等，一旦北上專線出現問題，上海側的高可用會失效不可用。
| 3.3 容災建設路徑
- 容災建設路徑：确定容災目标、制定容災标準、建設容災平台、夯實基礎能力、演練驗證和風險營運。
- 容災建設飛輪：内環是平台能力建設，從容災需求的提出到研發上線，體驗提升，使用者使用，發現問題提出新需求，不斷的疊代提升。另一個方面就是完善演練平台建設，開展高頻演練（或者真實故障驅動），發現問題、提出改進，促近平台能力持續疊代提升。
| 3.4 平台能力建設
為了建設提升資料庫服務的容災能力，内部成立了容災管控項目DDTP（Database Disaster Tolerance Platform），專注提升資料庫應對大規模故障的能力，核心包括基礎容災管控和故障演練兩大能力，分别對應兩個平台産品：一是容災管控平台，一個是資料庫演練平台。
容災管控平台主要專注于防守，它的核心功能主要包括事前逃生、事中觀測以及止損、事後恢複等，資料庫演練平台則專注于進攻，支援多種故障類型和多種故障注入方式，具備故障編排，故障複盤等核心能力。這個系列的第二篇《資料庫攻防演練建設實踐》就是對演練平台的詳細介紹。接下來，我們将重點介紹一下容災管控平台的主要内容，首先看一下全景圖：
- 資料庫服務：包括MySQL、Blade、MGR等基礎資料庫服務。
- 基礎能力層：主要是備份恢複、資源管理、彈性伸縮、主從高可用以及名額監控能力，這些能力是穩定性保障的基本部分，但在容災場景下需要進一步加強，以處理大規模故障場景。
- 管控編排層：核心是運維編排服務OOS（Operation Orchestration Service），會把基礎能力按需編排生成對應的處理流程也叫服務化預案，每個預案對應一個或者多個具體的運維場景。容災預案也在這個範疇。
- 平台服務層：是容災管控平台的能力層，包括：1）容災管控，容災計算評估和隐患治理，還有故障前容災逃生、故障中的兜底切換，故障摘流等。2）容災觀測，明确故障範圍，支援故障中的容災決策。3）容災恢複，故障後通過執行個體修複、叢集擴容等功能快速恢複叢集的容災能力。4）預案服務，包含了常見故障應急預案的管理和執行等等。
3.4.1 容量達标
資料庫建立了一套N+1容災計算标準，分為6個等級，如果叢集容災等級≥4級則容災達标，否則容災不達标。
從标準可以看出，從等級3開始就是多機房部署了。3級和4、5級的差別是，3級不滿足N+1要求，即如果一個機房的節點都出問題，剩餘節點無法承擔峰值流量。等級4、5都是具備N+1要求的，等級5會滿足region間容量對等。除基礎标準以外，SET化叢集有特殊規則，比如路由政策要閉環、SET叢集的綁定機房要統一、互備SET容量要對等、叢集内機型要統一等。這些規則都會納入容災計算來确定叢集的最終容災等級。
在基礎容災資料建設中，會把上述規則代碼化、計算流程化，通過近實時的方式做基礎資料“保鮮”。容災資料是容災管控平台上用于逃生切換和事中止損的基礎資料，同時還會基于容災資料建設風險隐患（即容災不達标隐患），并通過一定的營運治理來消除這種隐患。
3.4.2 故障前逃生
故障前逃逸能力就是批量主庫切換和從庫摘流，主要用于在故障前收到預警，提前感覺災難來臨，快速将一個機房的所有資料庫服務切走或者下線從庫流量，以降低真實故障帶來的影響。
我們知道對于主從架構的叢集，如果因為斷電或者斷網發生故障切換，很可能會發生資料丢失。資料一旦丢失，業務需要進行确認并做善後工作，有時候會非常繁瑣。如果能夠在事前逃走就會把這些風險都規避掉。同時除了主庫逃走以外，從庫也可以提前把流量“摘掉”，進而做到故障對業務方“無感”。
3.4.3 故障中觀測
在大規模故障發生的時候，一般會出現告警轟炸，電話咨詢轟炸等情況，如果沒有全局的故障感覺能力，就會使故障處理比較混亂，處理時間比較長，讓故障影響放大，是以我們建設了容災觀測大盤，它能夠實時、準确、可靠地對故障進行觀測，以確定值班同學能夠掌握故障的實時情況。
如下圖所示，如果發生了故障，可以快速拿到故障叢集或者執行個體清單，并在對應的頁面上發起兜底切換動作，進而實作快速止損。對觀測大盤的核心訴求就是要實時、準确、可靠。可以通過減少服務依賴來提升自身的可用性。
3.4.4 故障中止損
在介紹故障中的止損之前，先了解一下預案服務。預案服務的核心功能就是管理常見故障以及對應的各種處理預案，并提供執行控制能力，讓預案可以友善、可控地運作。
故障止損：在有了預案以後，我們就可以進行兜底止損。如下圖所示，當大規模故障發生的時候，HA會自動進行故障處理。如果叢集切換失敗或者漏切，那麼它就會進入兜底階段。首先從DDTP平台化兜底，如果平台受故障影響不可用，可以在運維編排層進行兜底。如果運維編排服務也失效，則需要人工通過CLI工具進行兜底。CLI是DBA最底層的工具，它和高可用是兩個獨立的鍊路。CLI會進行叢集拓撲探測、選主選舉、拓撲調整、配置修改、配置下發等邏輯，等同于手工叢集切換步驟。
總體原則優先提升高可用自動切換的成功率，減少透傳到兜底階段的叢集數量。其次提升預案可靠性，優先選擇白屏，逐級下沉，易用性下降，可靠性提升。
3.4.5 故障後恢複
雖然叢集具備N+1能力，一個機房故障的時候，叢集剩餘節點是能夠支撐峰值流量，但它不具備再一次AZ故障的容災能力，是以在故障後會根據各機房的資源情況，通過容災決策中心快速進行叢集擴容來補齊核心叢集的容災容量，使其重新具備AZ容災能力。
上述方案有一個比較大的弊端就是需要有足夠的資源來進行擴容，這是非常困難的，目前我們在建設更快速的恢複能力，如執行個體原地修複，叢集原地擴容等，在AZ恢複之後，可以快速複用發生故障的機房内的機器資源，實作容災快速恢複。
| 3.5 演練體系建設
各項基礎容災能力不能隻存在于架構設計、理論評估層面，必須實打實的可用，這就要需要通過演練進行驗證。容災管控項目之初，就制定了以演練為抓手的政策，驗證并驅動各項基礎能力的提升。截止目前，已經初步建成了多環境、高頻次、大規模、長鍊路的演練體系。
- 多環境：我們建設了多種演練環境，滿足各個PaaS元件的各類容災演練需求。一是容災管控平台的⻓穩環境，二是線下專用于演練的隔離環境，三是生産環境，有演練專區以及正常生産環境。
- 高頻次：目前能做到天、周級别。天級别屬于常态化的演練，主要是在長穩環境下自動發起，幾百個叢集的演練規模；周級别主要是在隔離環境、演練專區定期組織的斷網、斷電真實演練等。
- 大規模：是在生産環境開展的演練，用于驗證基礎高可用、兜底預案、逃生預案、容災恢複等功能的大規模、高并發處理能力，确定管控系統的服務容量。
- 長鍊路：整個容災鍊路涉及到很多元件，包括CMDB資料庫、流程資料庫，高可用元件，配置中心、預案服務等，我們會逐漸把這些元件都納入演練，可以讓一個或者多個元件服務同時故障，發現潛在問題，驗證多服務的多節點同時故障對于整個故障處理能力的影響。
3.5.1 隔離環境演練
隔離環境演練顧名思義，它是一套和生産機房完全隔離的演練環境，有自己獨立的TOR、機櫃，風險能做到完全隔離，可以開展獨立斷網或斷電操作。參與演練的PaaS元件和業務服務要在該環境獨立部署。在隔離環境除了會定期開展各種容災演練發現容災問題外，還可以驗證各PaaS的獨立部署能力，為國際化業務支撐提供基礎。
3.5.2 生産環境演練
- 常态化、大規模故障演練：此類演練是日常持續開展的，通過演練平台對資料庫叢集注入故障，高可用進行故障切換。通過不同的演練規模來驗證高可用的并發切換能力。此外，在容災管控平台上，可以驗證逃生能力、止損預案、及大規模故障的觀測等。總而言之，它是利用“攻”和“防”相結合的形式，實作能力的驗證驗收和優化提升。
這類演練主要特點：一是參演叢集都是由生産環境的高可用分組進行托管，就是說演練驗證的都是生産環境的高可用的能力；二是參演的大規模叢集是非業務叢集，是每次演練前新建立的專門用于演練的叢集，規模可以做到很大，目前可以常态化的進行1500+叢集同時進行演練；三是有一定的仿真效果，為使演練更為真實并對RTO做精準評估，對演練叢集增加了帶載能力。
- 真實專區演練：上文介紹的隔離環境演練、大規模演練都是偏模拟性質的，和真實的故障場景有比較大的差別。為了彌補和真實故障主鍵的GAP，我們基于公有雲建構了一個專用演練AZ，可以了解為就是一個獨立的機房。參演業務群組PaaS件将部分承載業務流量的服務節點部署到演練AZ中，實際演練的時候會進行真實的斷網，業務群組件可以在斷網的時候觀測和評估自己的容災情況。這種通過真實機房、真實元件叢集、真實的業務流量來驗證元件和業務的實際容災情況，會更加真實。
- Game Day：此外我們還在評估論證在真實機房開展演練的可行性，随着隔離環境演練、專區演練的常态化開展，各個元件的基礎容災能力會越來越強，在真實機房進行常态化機房演練的終極目标也會随之達成。
4 未來思考
經過兩年多的建設，雖然在高可用自動切換、容災能力營運治理、大規模故障觀測、故障止損預案、容災恢複等方面取得了一定的成果。但是還有很多能力短闆需要建設補齊，業務新的發展也帶來了新的需求和挑戰。未來我們會補齊短闆、疊代技術架構兩個方向上進行持續的提升。
| 4.1 補齊短闆
- 超大規模逃生能力、止損能力不足：随着我們自建資料中心的落地，我們自建的AZ規模會更大，這對能力的要求會更高，我們主要通過平台疊代和演練驗證逐漸提升能力。
- 跨域專線故障導緻Region級高可用失效：接下來我們會探索單元化方案或者獨立部署方案，實作Region級或者更細粒度的閉環管理。
- 業務出海新挑戰：出海會給容災架構帶來一些新需求和挑戰，是采用“長臂管轄”還是獨立部署，是複用現有技術體系還是打造一套全新架構，這些問題都還需要進一步的探索和論證。
- 容災效率問題：平台基礎功能已經相對完善，不過容災決策以及處理協同等還需要人工進行，效率相對較低，未來會把容災管控、應急止損等能力逐漸向自動化演進；多環境演練成本比較高，也要逐漸做自動化演練，把核心的演練場景逐漸納到長穩環境，通過定時或一定的政策讓它自動去跑故障場景，我們隻需要關注核心名額營運即可。
| 4.2 疊代架構
資料庫相關技術發展很快，比如Database Mesh、Serverless等新技術形态會逐漸落地，屆時中間件、高可用、核心等會有比較大的變化，新型用戶端HA方案的建設成熟及新Proxy架構，存計分離産品的引入都會使容災的能力發生比較大的變化。容災能力建設會随着這些确定的産品演進進行疊代。
容災建設是一件非常有挑戰的事，也是所有公司業務發展壯大後必須面對的一件事。歡迎大家在文末留言，跟我們一起交流。
5 本文作者
瑞超，來自美團基礎研發平台-基礎技術部。
來源:微信公衆号:美團技術團隊
出處:https://mp.weixin.qq.com/s/xSuc8FAvw5EldpNX0XFRAA