在進行系統架構設計時，您必須考慮到資訊系統和基礎設施可能遇到的各種潛在威脅，例如：硬體故障、軟體系統崩潰、人為操作失誤、安全攻擊、自然災害等。為了確保系統能夠在各種異常故障情境下快速恢複並保持商務持續性，您必須為系統設計一套完善的容災方案。本文以Kubernetes叢集（包括Container Service Kubernetes 版的ACK叢集、第三方雲廠商叢集和本地IDC叢集）為基礎，結合阿里雲的網路、資料庫、中介軟體及可觀測相關雲產品，為您介紹如何設計容災架構和方案，協助您構建一個更加有“韌性”的系統。
容災目標
Recovery time objective（RTO）：服務中斷與服務恢複之間可接受的最大延遲時間。決定服務停機的可接受時間長度。
Recovery point objective（RPO）：自上一個資料復原點以來可接受的最大時間量。決定可接受的資料丟失或重建。
對於RTO和RPO來說，數值越低表示服務停機的時間和資料丟失量越少，但是越低的RTO和RPO意味著資源成本和營運複性越高。因此，您需要考慮實際業務成本及營運成本制定適當的RTO和RPO。
容災策略
策略概述
如上圖所示，提供了三種常見的容災策略：備份與恢複、主備、雙活。不同容災策略的成本和收益均有所差異，您需要根據業務的重要性、資料丟失風險、可投入成本等進行綜合評估，選擇合適的容災策略。
備份與恢複（Backup-Restore）
如上圖所示，在備份與復原模式下，系統運行時會備份應用和資料，故障或災難發生時，系統會將備份的應用和資料在另一地點進行恢複，並切換業務流量。
由於資料無法即時備份，在恢複資料時會有一定的資料丟失，並且如果資料量較大時，恢復可能較長。
主備（Active-Standby）
如上圖所示，在主備容災模式下，主Location處理所有的業務流量，備用Location可以啟動較少的應用執行個體以節省成本，並周期性發送測試流量以驗證系統有效性。
在故障或災難發生時，系統進行資料庫主備切換，擴容備用Location中的應用執行個體數量，並將業務流量切換到備用Location上。
雙活（Active-Active）
如上圖所示，在雙活容災模式下，兩個Location啟動相同的應用執行個體數，同時處理業務流量。
在故障或災難發生時，系統進行資料庫主備切換，並將業務流量全部切換到正常的Location上。
容災範圍
多可用性區域（Multi-AZ）
阿里雲的一個地區（Region）通常會包含多個可用性區域（AZ），可用性區域是電源和網路互相獨立的物理地區，對於停電、斷網等局部中斷的容災情境，可以將多可用性區域加入到容災方案的設計中。由於可用性區域之間的網路延時較短，可以更容易實現資料部分的容災方案，包括資料庫、緩衝和訊息等。
關於地區和可用性區域的更多資訊，請參見地區和可用性區域。
多地區（Multi-Region）
為了應對更大範圍的災難故障事件，這些事件可能會影響同一地區的多個可用性區域，您可以將容災範圍擴大至多個地區。但由於地區間網路延時更大，容災方案的複雜度和實現成本較多可用性區域會更高一些。
容災範圍設計原則
在選擇多可用性區域或多地區容災方案時，需要重點考慮有狀態應用和依賴的雲產品（例如：資料庫、緩衝和訊息）是否支援多地區或多可用性區域容災。
方案與樣本
備份與恢複容災方案
公用雲跨可用性區域和跨地區的備份與恢複
方案架構如下：
方案設計思路如下：
通過ACK One備份中心備份ACK叢集中的應用。包括無狀態應用和有狀態應用，對於有狀態應用，在備份應用YAML的同時也可以備份相關Storage資料。
ACK One備份中心整合雲產品雲端硬碟快照，Apsara File Storage NAS，Object Storage Service和雲備份，分別支援應用YAML、雲端硬碟PV、檔案系統PV的一鍵備份。
備份後，可以隨時將應用和Storage資料恢複到任意地區和可用性區域的ACK叢集。
阿里雲資料庫服務的備份與恢複操作，可參見RDS MySQLDatabase Backup與恢複、RDS執行個體間資料移轉。
混合雲備份與恢複
方案架構如下：
方案設計思路如下：
通過ACK One註冊叢集，可以將IDC自建或者非阿里雲的K8s叢集接入到阿里雲ACK控制台。
接入ACK One註冊叢集後，通過ACK One備份中心，可以備份IDC自建和非阿里雲的K8s叢集中的應用，包括無狀態應用和有狀態應用，對於有狀態應用，在備份應用YAML的同時可以備份相關Storage資料。
備份後，可以隨時將應用（Deployment/Statefulset）和資料（PV/PVC）恢複到任意地區和可用性區域的ACK叢集。
方案總結
備份恢複方案實施成本較低，但RTO和RPO相對較長，且時間長短取決於資料量的大小和應用的複雜度。您可以藉助ACK One備份中心支援的全量備份+增量備份能力，減少RTO和RPO時間。
備份恢複作為容災的兜底方案，重要性很高，在系統營運的過程中，要保證備份的及時性和可恢複性。
另外，您還可以選擇備份恢複功能實現應用的跨叢集遷移，使用情境如下：
業務上雲，將本地IDC叢集中的應用遷移到阿里雲ACK叢集中，具體操作，請參見IDC應用上雲遷移。
叢集版本較老，版本升級有穩定性風險，可以先建立新版本叢集，通過備份恢複將應用遷移到新版本叢集運行。具體操作，請參見跨版本叢集遷移。
多叢集Service
在應用遷移過程中，由於應用數量較多需要分批遷移，同時應用之間存在調用關係。此時，在網路打通的前提下，可以使用ACK One艦隊多叢集Service實現應用Kubernetes Service的跨叢集訪問。
如下圖所示，ACK One艦隊多叢集Service，可以將Cluster1的Application2的Kubernetes Service（包含endpoints）注入到Cluster2中，Cluster2上的Application1可以訪問Cluster1上的Application2。
在專線拉通的前提下，通過ACK One註冊叢集，IDC和非阿里雲的K8s叢集也可以使用ACK One艦隊多叢集Service。
單地區多可用性區域容災方案
基於DNS流量分發
方案架構如下：
系統正常運行：
災難事件發生時系統運行狀態如下：
災難事件發生，AZ1不可用。系統進行主備切換，GTM將流量切換到AZ2，ACK Cluster2的應用執行個體自動擴充，中介軟體和資料庫進行多可用性區域高可用切換。
方案設計思路如下：
通過ACK One GitOps應用分發在2個ACK叢集中部署應用，實現基於Git倉庫的持續一致性部署。
通過全域流量管理（GTM）做DNS解析實現負載分發，並監控系統運行健康狀態，自動觸發容災切換。
每個AZ內，通過ACK Ingress實現7層流量管理。
備叢集和主叢集的應用版本相同，但備叢集節點較少、應用副本較少以節省成本。
在主系統不可用時，全域流量管理（GTM）會將服務網域名稱DNS解析到備用系統，完成主備切換。
由於流量的增長，備叢集中ACK HPA會擴容應用副本，進而觸發ACK Cluster Autocaler擴容叢集節點。
阿里雲中介軟體（訊息、緩衝）的跨可用性區域容災能力，可參見雲訊息佇列RocketMQ版執行個體規格、雲訊息佇列Kafka版執行個體規格、雲原生記憶體資料庫Tair災備方案。
阿里雲資料庫服務的跨可用性區域容災，可參見RDS MySQL資料庫搭建高可用架構。
本方案基於DNS流量轉寄，由於DNS緩衝，在災難事件發生時，部分業務依然會路由到主系統，可能會造成一定的資料丟失。
該方案需要在2個ACK叢集中分別配置並維護7層Ingress規則，成本較高。
基於ACK One多叢集網關
方案架構如下：
系統正常運行狀態：
災難事件發生時系統運行狀態如下：
災難事件發生，AZ1不可用。系統進行主備切換，多叢集網關（MSE雲原生網關）自動將流量切換到AZ2的ACK Cluster2中，ACK Cluster2的應用執行個體自動擴充。
方案設計思路如下：
通過ACK One GitOps應用分發在兩個ACK叢集中部署應用，實現基於Git倉庫的持續一致性部署。
通過ACK One多叢集網關定義標準K8s Ingress規則（YAML格式），實現7層流量治理，完成主備模式的流量分發。多叢集網關為跨可用性區域高可用。
備叢集和主叢集的應用版本相同，但備叢集節點較少、應用副本較少以節省成本。
可以發送特定
HTTP Header的測試流量，通過多叢集網關轉寄到備叢集以驗證工作狀態。在主系統不可用時，ACK One多叢集網關會自動將業務流量切換到備用系統，完成主備切換。
由於流量的增長，備叢集中的ACK HPA會擴容應用副本，進而觸發ACK Cluster Autocaler擴容叢集節點。
阿里雲資料庫服務的跨可用性區域容災，可參見RDS MySQL資料庫搭建高可用架構。
本方案為HTTP 7層流量轉寄，並配合7層健全狀態檢查，相對於DNS流量分發方案，主備切換時可大幅降低業務流量損失。
網關側統一支援基於Ingress規則的流量治理，相對於DNS流量分發方案，本方案合并了主備系統的4層負載平衡和7層Ingress網關，降低了系統複雜度和維護成本。
跨可用性區域雙活
以上兩個方案以主備模式為例，為您介紹單地區多可用性區域的容災系統架構，同樣的架構下，基於DNS流量分發和基於ACK One多叢集網關也同時支援雙活情境。並支援自訂配置流量分發比例（例如：40% : 60%），以及故障情境下的流量自動切換。
在雙活的情境下，每個叢集中的應用副本數需要根據流量分發比例確定，叢集中需要配置Auto Scaling能力，以支援流量切換情況下的流量增長。
方案總結
單地區多可用性區域方案的實現成本較低，可以利用雲產品（包括：雲原生網關，容器，中介軟體，資料庫等）多可用性區域部署和多可用性區域高可用能力，快速實現容災切換，對業務改造較小。
但此方案僅可應對單個可用性區域的災難和故障，無法應對地區級的災難故障。
單地區雲+IDC容災方案
該方案的架構與單地區多可用性區域容災方案類似，設計思路如下：
雲上VPC與IDC建立專線串連，打通管控與資料通道。
通過ACK One註冊叢集接入IDC叢集，使用阿里雲強大的可觀測和安全能力，統一管理IDC叢集和ACK叢集。
通過ACK One GitOps應用分發分別在2個叢集中部署應用，實現基於Git倉庫的持續一致性部署。
基於DNS流量分發（單地區雲上和雲下雙活）
方案架構如下：
基於ACK One多叢集網關（單地區雲上和雲下雙活）
方案架構如下：
多地區容災方案
如果業務規模大且重要性高，服務的使用者數量多範圍廣，單地區的容災方案則無法滿足業務高可用要求，這時就需要考慮多地區容災方案。在多個地區中獨立部署業務系統，保證每個地區的業務系統具有單獨閉環和提供完整服務的能力。
以下提供兩種多地區容災方案：
基於單個ACK One艦隊
基於多個ACK One艦隊
基於單個ACK One艦隊
方案架構如下：
設計思路如下：
通過部署DDoS高防和Web Application Firewall（WAF），保護服務免遭流量型攻擊和Web應用程式層攻擊，例如，SQL注入、跨站指令碼攻擊、命令注入等。
具體實踐方案，請參見全域流量管理&WAF&GA&SLB聯動和通過聯合部署DDoS高防和WAF提升網站防護能力。
通過全域流量管理（GTM）將使用者就近接入相應的地區。
通過ACK One GitOps應用分發在2個ACK叢集中部署應用，實現基於Git倉庫的持續一致性部署。
緩衝採用多地區高可用方案，更多資訊，請參見Tair全球多活。
資料庫採用跨地區高可用方案，更多資訊，請參見雲原生資料庫PolarDB MySQL多可用性區域部署架構。
地區內部署可採用單地區多可用性區域容災方案。
基於多個ACK One艦隊
方案架構如下：
設計思路如下：
通過部署DDoS高防和Web Application Firewall（WAF），保護服務免遭流量型攻擊和Web應用程式層攻擊，例如，SQL注入、跨站指令碼攻擊、命令注入等。
具體實踐方案，請參見全域流量管理&WAF&GA&SLB聯動和通過聯合部署DDoS高防和WAF提升網站防護能力。
通過全域流量管理（GTM）將使用者就近接入相應的地區。
通過各自對應的ACK One艦隊的GitOps應用分發在2個ACK叢集中部署應用，實現基於Git倉庫的持續一致性部署。
緩衝採用多地區高可用方案，更多資訊，請參見Tair全球多活。
資料庫採用跨地區高可用方案，更多資訊，請參見雲原生資料庫PolarDB MySQL多可用性區域部署架構。
地區內部署可採用單地區多可用性區域容災方案。
多地區單元化多活部署
和前面的多地區容災方案相比，多地區單元化多活部署方案需要設計分區規則，對應用和資料進行分區，使單元具有面向部分資料分區的完整服務能力，以此實現業務的安全隔離、水平擴充，並能夠服務於龐大的使用者群體。
在本方案中，一般將多個單元劃分為一個中心單元（擁有使用者資料）和多個子單元（分區後的詳細資料）。該方案的實現需要業務系統支援自訂分流規則、資料拆分等能力，並且需要各單元間進行互動，實施複雜度較高。
方案架構如下：