從金融多活標準看容災發展

　　在2021年2月7日，中國人民銀行釋出了《金融資訊系統多活技術規範》，將其作為指導金融行業標準。可以說金融業關係國計民生，維護金融資訊系統安全是國家資訊保安的重點，因發生災難導致金融服務中斷，可能對企業內部管理、公民、法人和其他組織的金融權益甚至國家金融穩定和秩序產生影響。為規範和引導在金融資訊系統合理運用多活技術實現業務承載和災難恢復，有效防範金融資訊系統風險，保護金融機構客戶的合法權益，特編制這一標準。本文針對這一標準並結合外部實踐經驗進行探討。

　　1. 容災技術背景說明

　　1).容災架構演進

　　最原始的系統架構非常簡單，客戶端請求進來，業務應用讀寫資料庫，返回結果即可。此時的架構是沒有考慮備份的，原系統出現問題後，無備份環境可用，不具備最基本的容災能力。

　　為了解決上述架構的問題，比較簡單的方式是提供備份系統。可在另一套環境中部署系統，但此時系統不啟動，僅做備份使用，故稱為“冷備份”。但出現問題時，啟動系統即可。這種方案解決了沒有備份系統問題，但恢復時間較長，需等待系統啟動後方可使用。

　　為解決恢復系統時間較長問題，可引入“熱備份”方式。顧名思義，這種情況是在另一套環境中部署系統且啟動，但這一系統不承擔任何業務訪問。只有當出現問題時，才進行切換，立即投入使用。這一方案解決了時效問題，但對於備用系統有效性無法驗證，且存在一定資源浪費。

　　為解決有效性及資源浪費問題，可升級為“只讀業務”方式。這種方式下，備份環境部署的啟動是工作的，但僅僅承擔只讀業務的訪問需求。其與熱備份方式的本質區別在於災難備份系統是否持續線上；對於熱備份方式，災難備份系統持續線上，其與只讀方式的本質區別在於是否承載業務。這一方案問題在於，無法驗證完整業務有效性及資源利用不足。

　　解決只讀業務方案問題，可利用災備備份系統提供允許資料寫入的業務。這裡分為兩種情況：一是部分業務，二是全量業務。對於限部分業務方式，是指在正常情況下，災難備份系統具備全部的業務功能，但限定只針對全部業務流量的一個子集提供服務，其與全量業務方式的本質區別在於是否針對全部業務流量提供服務。對於全量業務方式，災難備份系統在正常情況下，即可針對全部的業務功能和全部業務流量提供服務。對於這兩種情況，災難備份系統是“去中心化”的實現方式，其與生產系統之間並沒有明顯的主次之分，實現真正意義的“多活”。由於全量業務方式實現難度較大，價效比不佳，業內較少使用。對於限部分業務方式，在正常情況下，生產系統和災難備份系統均具備全部的業務功能，可透過設定一定的並行策略，約定和控制生產系統和災難備份系統分別承載部分流量；在災難發生時，部分系統發生癱瘓，只會影響其承載的部分業務流量，其系統只要具備快速接管業務的能力，仍可做到較小的業務中斷，保障業務連續性。

　　2).容災技術發展

　　❖ 冷備

　　為了解決應用及資料單點問題，最初引入了冷備技術。這裡談到的冷備包含多層含義。原始的需求，就是將資料放在異地進行備份。當主環境出現問題時，可利用異地備份還原資料即可。整個業務恢復時間取決於資料恢復時間及重新部署應用的時間。為了解決應用部署問題，後續將應用在異地進行部署，但不啟動，這樣解決了應用部署問題。為解決恢復資料時間問題，可透過資料庫的主從複製技術，提升資料完整度及故障恢復能力。無論上述如何改進，本質上來說都是冷備技術，備的部分不提供訪問能力，存在一定的資源浪費。

　　❖ 主備

　　為解決上面資源浪費問題，出現了主備技術。其基本結構上與冷備差異不大，更多是在備角色的使用上面。透過將部分應用部署到備，充分利用備的資源。但受到資料同步限制，無法做到完美一致性，同時是考慮將備充當讀取業務的承載，來分擔主業務壓力的同時，利用備的資源。為了充分利用備的應用能力，可以啟用備的寫應用，但是資料訪問上仍然是訪問主的資料。這種方式可以加快故障後的切換速度，同時也能啟動一定的驗證作用；但這種架構也有一個問題，就在於應對較大範圍故障問題存在不足，當發生如機房級故障時無法做到切換。

　　❖ 多活（雙活）

　　主備架構容災能力有限，也促生了多活架構。所謂多活架構，簡單來說是應用系統與基礎架構配合，透過將業務處理單元化實現更大範圍的容災能力。根據實現方式可分為同城雙活和異地多活兩種方式。這部分是本文的重點，後面會詳細說明。下圖來自阿里分享案例。

　　3).多活架構驅動因素

　　在傳統容災系統設計中，多采用主備方式。但從長期發展來看，其正向多活技術演進，其主要驅動因素有：

　　更高的災難恢復要求

　　對於主備方式，當災難事件發生後，災難備份系統接管業務往往需要經過較長的時間，而當前業務的特點對業務連續性提出了更高的要求。特別像金融行業，對可用性要求非常高。

　　接管能力難以把控

　　對於主備方式，災難備份系統在正常情況下並不承載真實業務，其真實接管能力難以有效評估，因對其接管能力的評估主要依賴於災難恢復預案的制定、管理及演練效果，故一旦災難發生，災難備份系統是否可接管真實業務難以保證。

　　單資料中心擴充套件受限

　　由於各方面的限制，單資料中心的擴充套件能力往往存在瓶頸，或者持續擴充套件能力的經濟效益降低。

　　資源利用率低

　　災難備份系統在正常情況下不承載業務，資源浪費嚴重。

　　技術提升需要

　　主備方式是在傳統技術架構的背景下提出的，而云計算、分散式等先進技術的成熟和應用推廣，為資訊系統災難恢復能力的升級提供了技術支撐。

　　業務覆蓋需要

　　對於覆蓋地理範圍較廣的業務系統，部分使用者業務接入的距離過長，可能由於處理延遲帶來使用者體驗的下降。

　　2. 多活架構方案設計

　　1).系統架構分層設計

　　對於按照多活架構設計的系統，通常可拆分為業務接入層、業務處理層、資料儲存層三層。其架構圖如下，各層的職能如下：

　　業務接入層主要負責業務多點接入和靈活路由，將業務流量按照一定的路由策略傳送至業務處理層；

　　業務處理層負責業務邏輯處理，並呼叫資料儲存層功能實現資料讀、寫；

　　資料儲存層負責接收業務處理層的呼叫進行資料持久化操作，實現資料的多點讀、寫功能。

　　解讀：何為“多活”

　　多地理節點部署

　　應用系統部署在多個地理節點，各地理節點的位置選擇宜綜合考慮電力、網路、供水等基礎設施的容災因素，包括獨立的空調、電力設施、計算、網路、儲存等物理資源。如上圖中部署單元，應部署在不同地理節點中。

　　多種佈局模式

　　根據地理節點的相對位置不同，多活系統的佈局模式可分為同城多活和異地多活。

　　業務並行多點接入

　　各部署單元同時支援業務接入，並支援靈活調整業務接入，部分地理節點災難故障不影響其他地理節點上部署單元的業務接入。

　　業務並行多點處理

　　各部署單元同時支援處理業務邏輯，並支援靈活調整，部分地理節點災難故障不影響其他地理節點上部署單元的業務處理。

　　資料並行多點儲存

　　各部署單元同時提供資料儲存，且保證其他部署單元存在與業務處理結果一致、可用的資料副本。部分地理節點災難故障不影響其他地理節點上部署單元的資料儲存。

　　部分業務影響和及時接管業務

　　當某個部署單元發生災難故障時，只有部分業務受到影響並需要分配到其他部署單元進行處理。當發生非區域性災難時，同城多活部署單元可及時接管業務；當發生區域性災難時，異地多活部署單元在較短時間內接管業務。

　　2).各層多活設計要求

　　❖ 應用接入要求

　　當應用系統要滿足多活需求是，需接入兩個或兩個以上部署單元。

　　若應用是從多點發起業務請求，應將應用系統多點均接入兩個或兩個以上的部署單元。

　　在部署單元不可用時，應用應保證及時將業務流量分配至其他接入的部署單元。

　　應保證對於某個接入路徑不可用時，其餘接入路徑具有足夠的網路頻寬和業務處理能力接管故障接入路徑的業務流量。

　　應支援對應用系統進行分級分類，設定差異化的接入要求，如接入專線數量、接入專線隔離要求、接入專線網路能力、業務流量分配變更時間等。

　　接入不同部署單元的網路鏈路宜具有相同的鏈路特徵，如網路頻寬、傳輸時延等。

　　應保證不因部署單元的業務流量分配變更造成網路地址衝突等問題。

　　應定期開展應用切換演練，以保證某個部署單元不可用時，可將原來透過該部署單元的業務流量分配到其他單元處理。

　　❖ 業務接入層要求

　　應支援應用系統同時接入兩個或兩個以上部署單元的業務接入層。

　　應支援將業務流量傳送至兩個或兩個以上部署單元的業務處理層，支援按路由策略對接入的業務流量進行路由選擇；對於業務流量轉發至異地部署單元的情況，可透過異地部署單元的業務接入層間接轉發。

　　應支援對路由策略進行實時控制。

　　應保證某個部署單元發生災難或故障時，其他部署單元具有足夠的業務接入能力，在較短時間內接管原由其接入的業務流量。

　　應支援根據業務邏輯實現使用者的業務流量路由的一致性，或透過與業務處理層協同工作以規避路由不一致對業務處理結果的影響。

　　裝置應冗餘部署，避免裝置單點故障對業務接入的影響。

　　網路線路應冗餘部署，避免單條線路故障對業務接入的影響。

　　應支援自動切換或集中切換功能，當出現參與方資訊系統與業務接入層之間故障、接入層內部故障、接入層與業務處理層之間故障、業務處理層故障時，可自動或集中切換路由，保障業務流量傳送至可用的業務處理層。

　　應支援對大於當前業務接入能力的業務流量進行限流，避免對部署單元造成影響。

　　❖ 業務處理層要求

　　應支援同時處理多個部署單元業務接入層轉發的業務流量。

　　應保證某個部署單元發生災難或故障時，其他部署單元具有足夠的業務處理能力，在較短時間內接管原由其處理的業務流量。

　　裝置應冗餘部署，避免裝置單點故障對業務處理的影響。

　　網路線路應冗餘部署，避免單條線路故障對業務處理的影響。

　　應滿足業務處理的無狀態要求，具體包括：多個部署單元的業務處理層應用之間解耦，不存在依賴關係；業務處理層將單次業務的處理結果傳送至資料儲存層儲存；業務處理層處理單次業務請求不依賴其他業務請求，業務處理過程中只使用來自單次業務請求攜帶的資訊以及資料儲存層儲存的資訊。

　　應滿足業務處理的冪等性要求，即單次業務請求與多次重複業務請求的處理結果一致，不因多次重複業務請求而產生不同的處理結果。

　　❖ 資料儲存層要求

　　應支援同時處理多個部署單元業務處理層的資料儲存請求，或者支援處理其他部署單後設資料儲存層的資料複製請求。

　　應保證某個部署單元發生災難或故障時，其他部署單元具有足夠的儲存能力接管原由其儲存的資料量。

　　業務資料應在多個部署單元的資料儲存層存在資料副本。

　　對有資料一致性要求的資料，應在同城部署單元具有滿足資料強一致性的副本，應在異地部署單元具有滿足在較短時間內達成資料最終一致性的副本。

　　3).多活關鍵指標設定

　　部署單元的關鍵指標包括多活業務集中度、多活同城業務集中度、多活業務接管時間、多活資料恢復點目標、多活接管容量能力，這些關鍵指標共同決定了多活資訊系統應對災難的能力。

　　多活業務集中度

　　用於衡量業務在各個部署單元之間的分散程度，降低多活業務集中度可降低單一部署單元災難或故障的業務影響範圍。例如：多活業務集中度為 25%，其可能實現方式是部署 4 個部署單元，並且在各部署單元間平均分配業務接入流量、業務處理流量和資料儲存量，當任何一個部署單元發生災難或故障，受影響的業務均不超過全部業務的 25%，其餘的業務不受任何影響。

　　多活同城業務集中度

　　用於衡量業務在各個不受同一區域性災難影響的地理區域間的分散程度，降低同城業務集中度可降低區域性災難的業務影響範圍。例如：多活同城業務集中度為50%，可能的實現方式是兩個地理區域分別部署兩個部署單元，並且在四個部署單元間平均分配業務接入流量、業務處理流量和資料儲存量；其他可能的實現方式是雙活資訊系統，兩個部署單元部署在不同的地理區域，平均分配業務接入流量、業務處理流量和資料儲存量。對於上述兩種實現方式，均滿足任何一個區域性災難發生後，受影響的業務不超過全部業務的 50%，其餘的業務不受任何影響。

　　多活業務接管時間

　　用於衡量災難發生後，對受到影響的部署單元業務流量重新分配並由其他部署單元接管的時間。降低多活業務接管時間，可減少災難引起的業務（部分業務）的中斷時間。

　　多活資料恢復點目標

　　用於評價當發生災難或故障時，部署單元中受影響的資料應恢復到的時間點要求。

　　多活接管容量能力

　　用於衡量災難發生後，部署單元承載受影響業務的能力，可用部署單元能承載受影響業務的百分比表示。例如，設定在單一部署單元故障時，其他部署單元可接管 100%的業務；設定對於任何區域性災難，其他部署單元可接管其 50%的業務。為了達到上述要求，需要合理分配部署單元的冗餘容量，同時還要考慮冗餘容量在各個部署單元之間的分佈，以及冗餘容量在不同地理區域之間的分佈。

　　3. 多活架構演進策略

　　1).系統演進策略

　　❖ 應用場景分析

　　向多活演進前提是進行業務影響分析，確定採用多活技術的業務範圍及其承載系統，然後評估向多活演進的可行性。

　　❖ 業務範圍分析

　　在向多活演進的業務範圍分析中，重點關注如下內容：

　　承載重要業務的系統宜考慮採用多活技術。

　　重要業務的支撐系統（如重要的認證和加密系統等）宜考慮採用多活技術。

　　已經出現處理能力瓶頸的系統，或業務突發性高的系統宜考慮採用多活技術。

　　❖ 可行性分析

　　在向多活資訊系統演進的可行性分析中，重點關注如下內容：

　　是否缺少成熟的多活解決方案和技術元件。

　　系統上承載各應用間的耦合程度，以及改造涉及範圍。

　　遷移至開放平臺的業務較容易實現多活。

　　可根據系統重要程度依次進行多活演進。

　　部分賬戶型系統對於資料一致性要求較高，建設異地多活的難度較大，集中式系統上可考慮保留一類結算賬戶及與之結合緊密應用。

　　宜優先採用開放式系統承載新增業務、處理效能有擴充套件要求業務、創新型業務（如網際網路金融等），以便於後續向多活系統演進。

　　2).系統演進路線

　　根據業務發展的不同階段對金融資訊系統業務連續性和災難恢復的要求，金融資訊系統向多活資訊系統的演進路線大致會經歷如下幾個階段，如圖：

　　階段一：生產系統和資料備份

　　對系統關鍵資料進行同城或異地備份。資料備份的週期可是實時或者定期。生產中心發生災難時，在災備中心臨時部署應用系統，載入關鍵資料，恢復業務服務。

　　階段二三：生產系統（同城）和災備系統（異地）

　　在同城或異地中心部署災備系統，並在生產中心和災備中心間建立資料同步，同步週期可實時或定期。日常由生產系統提供服務，生產系統發生災難時，由災備系統接管服務。災備系統啟動通常包括啟用災備中心繫統環境、啟動應用、載入資料、連通性驗證等工作。為了提高資源的利用效率，在日常情況下充分利用災備系統。部分金融資訊系統在上述方式的基礎上，由災備系統同時提供查詢服務，當發生災難事件時，由災備系統接管服務。災備系統接管服務通常包括暫停資料庫非同步複製、修改災備系統資料庫狀態、啟動災備系統應用環境、流量切換等工作。

　　階段四五：生產系統（同城雙/多活，異地多活）

　　從主備階段向雙活或多活演進的過程需要大量的業務梳理、系統能力評估、業務影響分析、風險分析等相關工作，還涉及到應用系統改造，對於不同的業務現狀和系統現有架構情況，存在很大的差異。最核心的工作涉及到將原有生產系統上的應用和資料進行拆分，並且根據拆分規則建立新的資料同步關係，同時實現應用並行業務處理相關的改造等，在拆分的過程需要額外注意資料的備份，並且具備出現異常後的回退機制。從架構上看，雙活可作為多活架構的一種特例來設計，但對於同城與異地則存在較大差異。下表簡單總結兩者區別：

　　4. 多活架構實踐說明

　　1).金融場景多活策略

　　下文根據金融行業特點，抽象出若干種場景，分析其多活策略。

　　流水型系統

　　流水型系統實現實時支付、證券交易、訂單等業務的發起方和接收方之間的轉接功能。典型的流水型系統是銀行渠道系統、轉接清算系統、非銀行支付機構的快捷支付（協議支付）系統等。對於此類系統，業務請求和業務請求響應需要實時轉發至業務發起方和業務接收方，對系統的實時性有較高的要求，但關鍵資料（如交易涉及的賬戶資料）的一致性由業務發起方和接收方保證，流水型系統對業務的流水資訊進行記錄。流水型系統的冪等性處理是架構設計的重點和難點，可採用多層冪等保障機制，如使用者發起業務流量環節冪等、實時業務處理環節冪等、交易對賬環節冪等。採用多活技術的流水型系統，可實現業務流水資訊（如訂單資訊、交易資訊等）的多點儲存和業務的多點轉接，各部署單元分擔流量，並且在部分部署單元發生災難或故障時，其他部署單元仍可接管業務流水資訊記錄和業務轉接。對於處於重要業務處理路徑上的流水型系統，採用多活技術可避免因流水型系統的災難或故障造成重要業務的全業務流程中斷。

　　賬戶型系統

　　賬戶型系統主要實現賬戶資訊、使用者資訊等業務資料的處理和記錄。此類系統需要優先保障關鍵資料的一致性，當災難或故障發生時，應在達到關鍵資料一致性的前提下，實現業務可用性。賬戶型系統的資料一致性是架構設計的重點和難點，應結合業務模型選擇解決方案，如關鍵資料採用同步複製等手段、將只讀資料和可寫資料分離、業務處理層與資料儲存層協調工作等。採用多活技術的賬戶型系統，可根據需要設計各部署單元的並行策略，將賬戶拆分到多個部署單元，並行進行賬務處理。當故障或災難事件發生時，只有部分賬戶受到影響，並將其業務流量變更至其他多活子資訊系統。

　　計算型系統

　　計算型系統實現清分清算、風險控制、商戶結算等相關的計算，還包括金融領域的各種科學、工程、資料分析、音影片處理等相關的計算。此類系統對輸入的業務進行計算，並將結果輸出至其他系統，計算過程所需資料全部來源於單次計算業務請求或外部系統。此類系統重點保障計算應用的可用性和準確性。採用多活技術的計算型系統，可實現多點計算、多點輸出結果。這樣可將多個部署單元的輸出結果相互核對，提高準確性，還可在部分部署單元災難或故障時，直接取用其餘部署單元的計算結果。在一些場景下，計算所需資料可能分散在分散式系統中，可能會採用多層級計算再彙總計算的方式。

　　查詢型系統

　　查詢型系統實現對使用者提供各種使用者資訊、交易記錄、交易行情、訂單記錄、釋出資訊等相關查詢。此類系統中的查詢應用不會對系統儲存的資料進行修改（或者查詢業務流量比率遠遠大於有資料寫入和修改的業務流量的系統），資料主要由外部系統匯入。此類系統重點保障查詢應用的可用性，以及被查詢資料的多副本儲存、被查詢資料的多副本之間的一致性，以保證各多活子系統查詢結果相同。採用多活技術的查詢型系統，可實現多點查詢。多個部署單元之間可分擔查詢流量，並且在部分部署單元出現災難或故障時，可透過其他部署單元查詢資訊。

　　2).多活設計常見誤區

　　所有業務都需異地多活

　　異地多活，是為了保證業務的高可用。所以本質上，還是要看業務的高可用需求。一般情況下，會優先保證核心業務支援異地多活。

　　資料實時一致性

　　異地多活本質上還是透過異地的資料冗餘，來保證極端情況下業務也能提供給使用者。因此資料同步是異地多活的核心，但完美的資料實時同步是不可能的。業務要求資料可做到實時同步，物理約束又限制資料無法完美同步。雖然可透過搭建高速網路、減少同步規模、減少業務對資料同步依賴等手段來緩解上面問題，但根本上還是需要根據資料業務特徵進行差異化處理，實現最終一致性滿足業務需求。

　　依靠儲存系統同步即可

　　資料同步是多活核心，一般儲存系統（如資料庫）都會有自身同步能力。雖然絕大部分場景下，儲存系統自身同步功能是夠用的，但在某些極端情況下還是有所欠缺。理想的做法是開拓思路，避免僅使用儲存同步功能，將多種手段配合儲存系統同步來使用，甚至可不採用儲存系統的同步方案，改用自有同步方案。

　　要做到業務100%可用

　　異地多活無法保證100%業務可用，這是由物理規律決定的，光速和網路傳輸速度、硬碟寫入速度、極端異常情況等，都是無法100%解決的。多活架構，透過單元化處理可滿足系統整體上大部分可用，但是要忍受一小部分業務的損失。不存在完美的多活方案，可透過掛公告、事後補償的方式進行安撫處理。