雲原生時代，企業多活容災體系構建思路與最佳實踐
對於雲原生的概念解讀，大家經常會聽到微服務、容器這些，那麼這些技術跟企業容災到底有什麼樣的關係？其實容災的需求各行各業都有，比如金融行業對於容災也有強烈的需求。但是怎麼把容災和多活能力構建起來，其實是每家企業都需要好好思考的。這篇分享希望能給大家提供一些相關思路。
容災 1.0：在原有應用系統的構建過程中，業務系統是基於傳統架構部署在機房裏面，那麼相關的應急措施或者故障處理的辦法呢？這個時期只考慮到了數據備份，主要以冷備的方式。除了提供業務的機房，另外可能會考慮到災難場景做額外的機房。從系統建設的角度，可能會選擇用單獨的機房把數據同步到另外的機房做冷備，在出現問題的時候切換。但在實際情況中，平時一般不會選擇切換機房，哪怕是每年做災備系統例行演練的金融行業，在生產過程中遇到系統出了問題的時候都不太敢切換。
容災 2.0：更多地考慮到了應用。比如雲原生，或者再往上層應用在傳統的 IOE 體系中，切換不僅僅是簡單地切過去，把原來冷備的數據加載出來，而是希望切過去的時候可以很快速地把應用在另外的機房拉起來。爲了實現數據層上的複製不會有太大延時，我們通常會有雙活的要求。但是一般做雙活會有一些要求，比如距離要求一定範圍以內纔可以做同城雙活。雙活更多會應用在 AQ 模式，即在生產這邊做全業務，在另外機房做別的業務。
容災 3.0：希望做成異地多活。多是什麼？意思是不再侷限兩個機房，更希望是三個或者更多的機房。比如阿里的業務分佈在多個機房，怎麼同時對外提供業務的支撐，這是需要對應技術支持的。而異地多活的意思就是不侷限於距離，比如 200 公里或者同城，因爲如今的機房部署在全國各地。
業務連續性以及容災概述
對於業務連續性來說其實有體系化的方法，指在容災系統建設上多年積累下來的規範和指導，這其中有幾個維度：
1、多活業務並不是跟原來的容災一樣，把對等在另外一個機房一樣的業務直接拉過去，而是選擇有價值的業務。因爲在容災系統建設中，要把所有的業務實現多活，在成本和技術實現上是非常困難的。
2、實時性運行的保障，需要保證核心業務不會因爲機房斷電等各種原因停止服務。
3、M 代表保障體系。如今各行各業，可能都有自己不同的手段和管理的方式，而阿里提供的是將這一部分的東西轉變爲技術、工具和產品，讓大家未來在構建多活能力的時候，可以很快速地基於這套方法和產品構建業務的多活。
BCM 體系和 IT 容災恢復能力是一個偏實踐的指導性框架。從完整性來講，頂部的業務連續性是目標，下面是各種實現方式。在底部可以看到例如 IT 計劃，業務連續性出現特殊問題處理故障的計劃等，這些在原來做容災的時候是會考慮到的，而我們是從多活的角度把這些東西考慮在產品體系裏面。
這裏提到的幾個容災方式，其實是比較常見的：從冷備到同城雙活、同城雙活加異地冷備（兩地三中心），這些在業內相對來說都是比較規範的方式。而異地多活就好比在兩地三中心的三個機房裏面同時提供多活的能力，在以前的基礎上，又跟原來傳統的容災有一些區別。多活在建設成本上與傳統也有區別，比如構建異地多活的能力，在建設成本上比傳統（例如同城雙活和兩地三中心）會有更多的投入。
在構建多活能力的時候，其實也會考慮到業務的實際情況。比如不同的行業，或者比如在多活方面只要求實現兩邊的讀，那麼不同情況下，建設成本以及對業務切換的時間是有區別的。異地多活能力從橫向時間軸來看的話可以做到分鐘級切換，但如果基於冷備的話可能需要以天來切換。
阿里爲什麼做多活
在阿里的業務模式下，爲什麼要做多活的原因跟前面提到的類似。前面講到的同城加冷備，如果不採用多活就要建另外一個機房，成本非常高，因爲那個機房只是用作平時的數據同步，並不處在運行狀態，在這期間還需要不間斷地更新生產系統對應的版本和災備系統的版本。但實際情況下，原來的冷備或者兩地三中心出現故障的時候不敢去切換，因爲很有可能切換後就無法切回來。
而做多活主要有三個主要的訴求：
1、資源。隨着今天業務高速發展，單地資源容量受限。我們知道雲原生、雲計算提供高可用、容災的能力，但是雲計算部署在不同的機房裏面，跨地域多活的能力本身需要底層的基礎設施來支持，我們希望把業務擴展到不受限於物理機房的限制，還達到多個機房同時接業務；
2、業務有多元化的需求，需要就地或異地部署的要求；
3、針對容災事件。比如光纜挖斷，或者天氣原因機房供電散熱的問題，這些都會導致單機房的故障。如今的需求希望不受限於某個機房，而是有多個機房部署在全國各地處於不同的形態，根據業務模式可以靈活調控。
因爲這些訴求對多活的能力要求比較迫切，所以阿里根據自己的業務需求和技術上的能力做了多活的方案和產品。
多活架構的拆解
1、異地互備：今天大家講雲原生有多好，雲計算有多好，沒有多活能力這些技術其實就是閒置的狀態。冷備狀態時不工作，而在什麼狀態下要切到冷備大多要靠人的決策。由於層層上報對業務影響比較大，比較成熟的客戶會有一些預案，比如什麼樣的影響和故障需要做這種切換，但實際上基於冷備模式的話一般不敢去做切換。
2、同城雙活：有一定的距離限制，常見的雙活模式在上層應用這一層，比如像雲原生的 PaaS 層兩面機房都可以分發。在數據這一層因爲是同城可以用貯備的方式，主機房出現問題數據庫方面切到備機房，但是這個好處是兩邊機房的機器、資源都屬於活動的狀態。另外，機房處於活動的狀態就不用擔心生產的版本跟備機房的版本有區分，不會不敢切。
3、兩地三中心：除了考慮同城提供這個問題，對於故障應對能力會更強，在異地建一個冷備的機房，這個跟冷備第一個方案有類似，冷備的機房平時是不用的，可能會做一些其他的同步，只有在故障發生的時候做切換。
4、異地多活：有多個數據中心同時對外提供業務的能力。由於距離的侷限，在數據層面的複製可能會受限於網絡，導致延時的問題是一定會存在的。這其中有很多技術問題要解決，比如怎麼做到可以很快速從北京機房切換到上海，底層的數據受物理限制情況下沒有完全同步怎麼去切。我們操作模式不像原來容災的方式切換，而是要做一堆準備工作和後續數據的補償流程。我們將這套東西融合到產品體系中，物理極限沒有辦法突破我們就用架構的模式來優化。
遞進式多活容災架構
對於關鍵核心業務，其實在做多活系統或者項目的時候，對業務會做一些梳理，今天講的是單元化的梳理。
遞進式多活容災架構
雙讀、兩地三中心，一般情況下兩個機房最多一半一半去分，這是最簡單的。按照這種模式能找出業務切分的規則，比如可以按照用戶號碼，就像銀行可能按照卡號或者用戶所屬地分成一半一半的業務。而在多活裏面我們希望可以靈活去配，比如機房的處理能力多大，碰到的故障是什麼樣子，流量可以調成 50%、60% 或者其他比例。在多個機房也一樣，可以統一分配流量接入的情況。
在技術方面，像異地互備就是單向的數據複製，異地的雙活是雙向的，雙向的意思是這兩個機房某一個機房任何一個都有可能出問題，可以互相切換。這其中很重要的是技術上的實現，在數字這一層要想辦法去避免循環複製的問題，不能在把數據同步之後，另外一個機房認爲是新增的數據又複製回來。而在多個機房的情況下，傳統方式是在數據庫內用序列號，在多活裏面序列號需要規則生成具有全局唯一性，並且不是基於某一個單機房而是基於整個集羣，我們需要考慮多個機房生成的序列號不能有重複，這就需要產品具備一些規則來解決這個問題。
多活容災方案
多活產品方案的架構圖
1、接入層：在多活裏面第一個要解決的是非常重要的流量接入層。接入層可以很精細控制接入的規則，按照業務分片的規則，要精確到要映射到下層每一個機房，流量進來以後需要判斷流量用戶應該在哪個機房提供服務。這在實際情況中具體是如何實現的呢？
傳統的方式是域名切換。例如前端的域名有兩個機房，切換的時候把域名的地址切了，那麼整個業務原來是接到機房 A 的，通過域名可以切換到另一個機房 B 。這個方法的問題在於會影響正在做的業務。舉個例子，某一個機房出現問題後需要快速把業務切到另一個機房，通過域名切換的話，最底層正在進行的業務會受到影響。除此之外，這種底層切換沒辦法跟整個雲原生 PaaS 層做聯動，上層切了下層感知不到，根本不知道前面流量已經切換到另外的機房裏了，包括中間的調用可能還在原來機房單元裏面，這對於業務連續性來說其實受影響比較大。在極端的情況下用這種模式可以解決一些問題，比如一個機房一點業務都做不了且有備用機房的情況下，那麼把域名切過去也是一種辦法。
另一個辦法是用雲原生微服務，可以在微服務裏面對流量做打標，打標完之後在雲原生的微服務技術體系裏面把這個標記往下傳，儘可能把請求認爲在某個單元或者某個機房做，不能跳到其他機房。
2、應用層：中間這一層接入路由的規範包括服務路由的組件，是我們這個產品體系裏面可以單獨提供的。比如一些客戶說不想用全套的方案，因爲方案的中間這一層用的開源組件他可能都有，但又想實現多活的能力。那麼上層可以是用我們整個多活的管控切流，精確定義出來有多少邏輯的單元，並且提供 API ，供中間調用。全局唯一的序列號、路由規則和分片規則都有前面這一層提供給他。而這其中像打標和流量識別等看似比較簡單，實際上例如在多活的場景裏面，一些在拆分解耦的時候會用到的分佈式消息，以及在架構裏用到的消息，如果在某個機房沒有消費完就進行了切換，那麼需要用什麼方式同步到另外機房，這類問題都需要藉助雲原生來解決。
3、數據層：涉及到複製、寫入的邏輯。我們方案中的禁寫管控在數據庫上會有一個邏輯，即一旦在前端發生切換會自動生成代碼。比如說被切換的目標機房什麼時候數據恢復了，就會自動生成帶時間的代碼，只有當數據恢復了纔會把寫入的動作重新放開。我們會通過禁寫來保障對數據庫的保護和數據庫延時的判斷。如果底層數據同步能力不夠強，切換及大部分業務還可以做，但很多寫入的業務不一定能做了，因爲數據庫受禁寫規則的限制。另外數據同步的規則，在多個機房邏輯下對於複製的要求在整體規則上管控更高。
基於整套方案體系，我們提出了一個概念（如上圖所示）：MSHA 四個字母的縮寫代表的就是今天提供雲原生這一塊多活產品的能力，我們希望在這四個數字上面發揮小作用：0、1、5、10 分鐘的預防。
首先是 0 分鐘預防，前面提到切流，可以在兩個機房部署藍綠髮布的環境，這是一種方法。就算同一個機房也可以在管控臺的邏輯下定義出來兩個單元，很快速的在同一個機房裏進行藍綠髮布。一個機房做藍綠髮布受限於技術產品的支撐，通過這個組件可以很清晰劃出來，哪些資源是屬於其中一個單元的，哪些資源是另外一個單元的，同時對這個單元快速去實現藍綠髮布；
第二，5 分鐘定位，原來同城的比如冷備容災技術，往往做決策非常費勁，或者誰做切換要承擔後果，我們更希望基於這個平臺能直觀看到今天故障影響的情況，相關對應出現什麼問題干係人需要做什麼樣的動作，或者做什麼操作，把應用恢復起來；在發生故障的時候快速通過這套體系發現故障的問題，比如說通過 5 分鐘定位問題後，再由它來發起決策要不要做切流；
第三，10 分鐘恢復，最後，我們希望通過這套模式能把整個業務重新運作起來的整個過程控制在 10 分鐘內恢復。
多活容災最佳實踐
下面有幾個例子是阿里給外部企業應用的案例，這個多活容災能力不只有在公有云上可以用，因爲雲不代表當應用部署在雲上面的時候，天然所有的高可用就都是由雲來提供的，用資源的時候就會發現雲其實有不同的區域，同一個地區含有不同的可用區。在公有云上使用的時候是需要結合實際情況的，比如大部分客戶可能在南邊，那麼在南邊的機房可能會先開一個節點，那麼當阿里機房出現了問題的時候，客戶的業務也會相應收到影響，雖然客戶部署在雲上對應的業務，雲上的產品也提供高可用，但故障的場景一旦涉及到機房，對應的業務仍舊會收到影響。所以提供的方案是多活能力除了可以部署在雲上，也可以跟商業軟件一樣部署在機房。
案例一：同城雙活
某物流的客戶，其實是同城的範圍內使用了多活，雖然用傳統的技術問題也不大，用多活的好處體現在比如說有對應的 SDK ，可以自動識別出來，不需要業務做太多的改造，可以把打標的請求自動傳遞下去。容災能力在做完之後在 RTO 這塊比原來快了很多。
案例二：異地雙讀
異地雙讀的這個案例難點在於異地超過上千公里。在這個距離限制下，不管是讀還是寫其實都有難度，數據複製本身就存在延時，用這套產品的邏輯也是希望統一從管控、流量這一層很清晰知道，哪些是讀的業務，哪一些業務導入到讀的機房，複製的狀態是什麼樣的。分鐘級 RTO 比原來有很大的提升，可以在線動態地做業務的靈活切換。
案例三：異地雙活
使用異地雙活的這個企業客戶目前是有兩個機房寫，將來可能會往前拓展。做這個方案落地的時候做了很多產品上適配性的開發，因爲要實現讀的話，原來產品的基礎能力，有大量的工作在中間這一層，整個過程是從多活產品研發再往前適配應用場景，再到全面跟業務做改造。核心點是業務連續性，所以不是指所有的業務將來在機房裏都採用多活，而是僅針對關鍵的業務。舉個例子，比如說每年雙十一，我們核心的業務是保證下單不能有影響，那麼物流通過解耦或是其他方式，從業務連續性來講優先級不會像下單交易類這麼高。核心交易鏈路所涉及到的服務、產品在多活的維度以什麼方式保證切換的時候不會出問題纔是重點。
這個多活管控平臺建議大家親身體驗一下。兩個或多個單元在控制檯裏面定義出來後，當其中一個機房出現故障時，我們希望通過多活快速把它的應用切換到另一個機房時。切換的前提是需要定義出管控臺內的點，不管是單個機房邏輯的點，還是多個物理機房的點，都要映射到多活管控平臺裏面。在管控臺內我們會配一些規則，比如說單一化業務的接入，以什麼維度去切分接入的流量，或者以 ID 的方式標記。在切流的時候動態顯示哪些維度的流量到另一個機房，出現故障的時候可以快速去配，這就相對比較簡單。
如今我們幫助客戶部署能力，也會經常在體系裏面通過控制檯做一些切流和演練，來看一下這個機房是否受到一些影響，因爲整個系統裏面還配套其他的一些方案，比如做故障演練，配合這些故障把應用切換到另外一個機房等等。
總結
多活容災的能力在阿里內部業務中已經實踐很多年，將其演變成產品也花了很長時間，目的是希望今天這套產品和方案可以幫助企業在 30 天以內就可以構建起來自己的多活能力。特別是公有云上有很多產品部署都已經是現成的企業，其實構建起來時間耗費會更短。我們希望通過這套產品和方案多活的能力可以幫助企業快速在分鐘級實現故障的切換和多活能力的構建。
解決方案諮詢技術交流羣：搜索釘釘羣號 31704055 加入釘釘羣，可獲取雲原生詳細解決方案資料與專家答疑。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/8D60HsyF1emMn6QlKsQURg