在進行系統架構設計時，您必須考慮到資訊系統和基礎設施可能遇到的各種潛在威脅，例如：硬體故障、軟體系統崩潰、人為操作失誤、安全攻擊、自然災害等。為了確保系統能夠在各種異常故障情境下快速恢複並保持商務持續性，您必須為系統設計一套完善的容災方案。本文以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。
單地區多可用性區域多活容災方案
在單地區多可用性區域容災情境下，通常選擇多活容災方案。與同城多可用性區域的主備容災方案相比，多活容災具備以下優勢：
資源使用率更高、成本更低。
更高的服務品質和更強的容錯能力：服務副本增多，提升了服務品質、響應速度等，更好地應對流量高峰。出現故障時不會因流量切換導致服務中斷，並且可以支援在不中斷服務的情況下進行系統升級或維護。
擴充能力更強：某可用性區域資源不足時，可以快速在其他有資源的可用性區域擴充。
基於ACK One多叢集網關
方案架構如下：
系統正常運行狀態：
災難事件發生，AZ1不可用。系統進行主備切換，多叢集網關（MSE雲原生網關）自動將流量切換到AZ2的ACK Cluster2中，ACK Cluster2的應用執行個體自動擴充。
方案設計思路如下：
通過ACK One GitOps應用分發在兩個ACK叢集中部署應用，實現基於Git倉庫的持續一致性部署。
通過ACK One多叢集網關定義標準K8s Ingress規則（YAML格式），實現7層流量分發。多叢集網關本身為跨可用性區域高可用。
當Cluster1（或其中的應用）不可用時，ACK One多叢集網關會自動平滑地將Cluster1上的業務流量轉移到Cluster2，完成故障自動轉移。
由於流量的增長，Cluster2中的ACK HPA會擴容應用副本，進而觸發ACK Cluster Autoscaler擴容叢集節點。
阿里雲資料庫服務的跨可用性區域容災，可參見RDS MySQL資料庫搭建高可用架構。
本方案為HTTP 7層流量轉寄，並配合7層健全狀態檢查，相對於DNS流量分發方案，主備切換時可大幅降低業務流量損失。
網關側統一支援基於Ingress規則的流量治理，相對於DNS流量分發方案，本方案合并了主備系統的4層負載平衡和7層Ingress網關，降低了系統複雜度和維護成本。
方案總結
單地區多可用性區域方案的實現成本較低，可以利用雲產品（應用型負載平衡，雲原生網關，容器，中介軟體，資料庫等）多可用性區域部署和多可用性區域高可用能力，快速實現容災切換，對業務改造較小。
相比於基於DNS流量轉寄的單地區多可用性區域容災方案，基於ACK One多叢集網關來實現的方案，具有以下優勢：
地區級的全域負載平衡，統一管理多叢集南北七層流量：減少網關數量，降低費用成本。DNS方案無法支援某些跨叢集的路由能力，如QUIC的0-RTT特性需要會話保持。
毫秒級/秒級容錯移轉，無DNS用戶端緩衝問題。
多叢集網關方案：某叢集服務發生故障，可毫秒級/秒級重新路由流量至其他叢集，容錯移轉相比DNS方案更平滑。
DNS方案：故障時切換IP，通常會因用戶端緩衝造成服務短暫（分鐘層級）不可用。為瞭解決緩衝問題，通常採用減少TTL值的方式，這又會帶來大量的DNS訪問請求，產生更高使用成本。
簡化管理：在一個控制台（艦隊）管理Ingress配置和服務，更容易擴充和維護服務或應用，降低管理成本。
叢集升級或重建時透明的叢集遷移：通過規則將流量遷移到健康叢集，升級或重建完成後再轉寄回來。
DNS流量轉寄方案如下圖：
單地區雲+IDC容災方案
該方案的架構與單地區多可用性區域容災方案類似，設計思路如下：
雲上VPC與IDC建立專線串連，打通管控與資料通道。
通過ACK One註冊叢集接入IDC叢集，使用阿里雲強大的可觀測和安全能力，統一管理IDC叢集和ACK叢集。
通過ACK One GitOps應用分發分別在兩個叢集中部署應用，實現基於Git倉庫的持續一致性部署。
基於ACK One多叢集網關（單地區雲上和雲下雙活）
方案架構如下：
多地區容災方案
當業務規模龐大且使用者覆蓋廣泛時，單一地區的容災方案可能無法充分保障業務的高可用性。在此情況下，應考慮實施多地區容災方案。在多個地區獨立部署業務系統，確保每個地區的系統能夠獨立運行並提供完整的服務。在多地區容災情境中，可以選擇基於ACK One多叢集網關的容災系統或基於DNS流量轉寄的容災系統，各自適用於不同的應用情境。
方案一：基於ACK One多叢集網關
ACK One支援通過ALB多叢集網關來快速實現多地區容災系統，該方案主要適用以下情境。
跨地區高可用、本地區資源不足。例如在AI熱潮的當下，GPU資源異常緊缺等情況。
用戶端應用對時延不十分敏感，但需要更強的多叢集流量管理能力。
基於ACK One多叢集網關的異地容災系統方案，具有以下優勢：
Region 1的ALB多叢集網關用於處理跨地區的7層流量轉寄，如QUIC的0-RTT、基於header轉寄等。Region 2則配置了單叢集ALB執行個體作為冷備，用於在Region 1宕機後將流量容錯移轉至Cluster 2。
通過全域流量管理做DNS解析實現負載分發，並監控多叢集ALB和單叢集ALB健康狀態，自動觸發容災切換。
當Region 1的整個地區或其應用負載平衡（ALB）服務出現故障時，全域流量管理（GTM）會將服務網域名稱的DNS解析切換至Region 2的ALB，實現容災切換。若僅Region 1的叢集或服務出現異常，或者Region 2發生宕機，ALB多叢集網關將自動將流量切換至健康的叢集，無需依賴GTM，即可實現更平滑的容錯移轉。
Cluster 1和Cluster 2通過CEN或VPC對等串連等方式打通後，跨地區流量通過專線轉寄，保證可靠性。
緩衝採用多地區高可用方案，更多資訊，請參見Tair全球多活簡介。
資料庫採用跨地區高可用方案，更多資訊，請參見多可用性區域部署架構。
基於ACK One多叢集網關的異地容災系統方案，具有以下優勢：
更強的多叢集路由轉寄能力：提供基於內容的進階路由功能，以及比傳統GTM更靈活的健全狀態檢查機制，以適應更複雜的應用情境。
統一多叢集流量管理入口：通過一個控制面（艦隊）管理Ingress配置和服務，更容易擴充和維護服務和應用，降低管理成本。
緩解DNS用戶端緩衝問題：通過容災情境可以看出，高頻率服務異常或叢集異常，無需DNS切換網域名稱解析IP，可毫秒級/秒級容錯移轉。
方案二：基於DNS流量轉寄+單個ACK One艦隊
基於DNS流量轉寄的多地區容災方案，優勢在於其全域流量管理為全球層級，適用於就近訪問等情境。方案架構如下：
設計思路如下：
通過部署DDoS高防和Web Application Firewall（WAF），保護服務免遭流量型攻擊和Web應用程式層攻擊，例如SQL注入、跨站指令碼攻擊、命令注入等。具體實踐方案，請參見全域流量管理&WAF&GA&SLB聯動和通過聯合部署DDoS高防和WAF提升網站防護能力。
通過全域流量管理（GTM）將使用者就近接入相應的地區。
通過ACK One GitOps應用分發在兩個ACK叢集中部署應用，實現基於Git倉庫的持續一致性部署。
緩衝採用多地區高可用方案。更多資訊，請參見Tair全球多活。
資料庫採用跨地區高可用方案。更多資訊，請參見雲原生資料庫PolarDB MySQL多可用性區域部署架構。
地區內部署可採用單地區多可用性區域容災方案。
方案三：基於DNS流量轉寄+多個ACK One艦隊
方案架構如下：
設計思路如下：
通過部署DDoS高防和Web Application Firewall（WAF），保護服務免遭流量型攻擊和Web應用程式層攻擊，例如，SQL注入、跨站指令碼攻擊、命令注入等。具體實踐方案，請參見全域流量管理&WAF&GA&SLB聯動和通過聯合部署DDoS高防和WAF提升網站防護能力。
通過全域流量管理（GTM）將使用者就近接入相應的地區。
通過各自對應的ACK One艦隊的GitOps應用分發在兩個ACK叢集中部署應用，實現基於Git倉庫的持續一致性部署。
緩衝採用多地區高可用方案，更多資訊，請參見Tair全球多活。
資料庫採用跨地區高可用方案，更多資訊，請參見雲原生資料庫PolarDB MySQL多可用性區域部署架構。
地區內部署可採用單地區多可用性區域容災方案。
多地區單元化多活部署
和前面的多地區容災方案相比，多地區單元化多活部署方案需要設計分區規則，對應用和資料進行分區，使單元具有面向部分資料分區的完整服務能力，以此實現業務的安全隔離、水平擴充，並能夠服務於龐大的使用者群體。
在本方案中，一般將多個單元劃分為一個中心單元（擁有使用者資料）和多個子單元（分區後的詳細資料）。該方案的實現需要業務系統支援自訂分流規則、資料拆分等能力，並且需要各單元間進行互動，實施複雜度較高。
方案架構如下：