在进行系统架构设计时，您必须考虑到信息系统和基础设施可能遇到的各种潜在威胁，例如：硬件故障、软件系统崩溃、人为操作失误、安全攻击、自然灾害等。为了确保系统能够在各种异常故障场景下快速恢复并保持业务连续性，您必须为系统设计一套完善的容灾方案。本文以Kubernetes集群（包括容器服务 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备份中心集成云产品云盘快照，文件存储NAS，对象存储OSS和云备份，分别支持应用YAML、云盘PV、文件系统PV的一键备份。
备份后，可以随时将应用和Storage数据恢复到任意地域和可用区的ACK集群。
阿里云数据库服务的备份与恢复操作，可参见RDS MySQL数据库备份与恢复、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应用防火墙（WAF），保护服务免遭流量型攻击和Web应用层攻击，例如SQL注入、跨站脚本攻击、命令注入等。具体实践方案，请参见全局流量管理&WAF&GA&SLB联动和通过联合部署DDoS高防和WAF提升网站防护能力。
通过全局流量管理（GTM）将用户就近接入相应的地域。
通过ACK One GitOps应用分发在两个ACK集群中部署应用，实现基于Git仓库的持续一致性部署。
缓存采用多地域高可用方案。更多信息，请参见Tair全球多活。
数据库采用跨地域高可用方案。更多信息，请参见云原生数据库PolarDB MySQL多可用区部署架构。
地域内部署可采用单地域多可用区容灾方案。
方案三：基于DNS流量转发+多个ACK One舰队
方案架构如下：
设计思路如下：
通过部署DDoS高防和Web应用防火墙（WAF），保护服务免遭流量型攻击和Web应用层攻击，例如，SQL注入、跨站脚本攻击、命令注入等。具体实践方案，请参见全局流量管理&WAF&GA&SLB联动和通过联合部署DDoS高防和WAF提升网站防护能力。
通过全局流量管理（GTM）将用户就近接入相应的地域。
通过各自对应的ACK One舰队的GitOps应用分发在两个ACK集群中部署应用，实现基于Git仓库的持续一致性部署。
缓存采用多地域高可用方案，更多信息，请参见Tair全球多活。
数据库采用跨地域高可用方案，更多信息，请参见云原生数据库PolarDB MySQL多可用区部署架构。
地域内部署可采用单地域多可用区容灾方案。
多地域单元化多活部署
和前面的多地域容灾方案相比，多地域单元化多活部署方案需要设计分片规则，对应用和数据进行分片，使单元具有面向部分数据分片的完整服务能力，以此实现业务的安全隔离、水平扩展，并能够服务于庞大的用户群体。
在本方案中，一般将多个单元划分为一个中心单元（拥有用户数据）和多个子单元（分片后的详细数据）。该方案的实现需要业务系统支持自定义分流规则、数据拆分等能力，并且需要各单元间进行交互，实施复杂度较高。
方案架构如下：
