在进行系统架构设计时，您必须考虑到信息系统和基础设施可能遇到的各种潜在威胁，例如：硬件故障、软件系统崩溃、人为操作失误、安全攻击、自然灾害等。为了确保系统能够在各种异常故障场景下快速恢复并保持业务连续性，您必须为系统设计一套完善的容灾方案。本文以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。
单地域多可用区容灾方案
基于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%），以及故障场景下的流量自动切换。
在双活的场景下，每个集群中的应用副本数需要根据流量分发比例确定，集群中需要配置弹性伸缩能力，以支持流量切换情况下的流量增长。
方案总结
单地域多可用区方案的实现成本较低，可以利用云产品（包括：云原生网关，容器，中间件，数据库等）多可用区部署和多可用区高可用能力，快速实现容灾切换，对业务改造较小。
但此方案仅可应对单个可用区的灾难和故障，无法应对地域级的灾难故障。
单地域云+IDC容灾方案
该方案的架构与单地域多可用区容灾方案类似，设计思路如下：
云上VPC与IDC建立专线连接，打通管控与数据通道。
通过ACK One注册集群接入IDC集群，使用阿里云强大的可观测和安全能力，统一管理IDC集群和ACK集群。
通过ACK One GitOps应用分发分别在2个集群中部署应用，实现基于Git仓库的持续一致性部署。
基于DNS流量分发（单地域云上和云下双活）
方案架构如下：
基于ACK One多集群网关（单地域云上和云下双活）
方案架构如下：
多地域容灾方案
如果业务规模大且重要性高，服务的用户数量多范围广，单地域的容灾方案则无法满足业务高可用要求，这时就需要考虑多地域容灾方案。在多个地域中独立部署业务系统，保证每个地域的业务系统具有单独闭环和提供完整服务的能力。
方案架构如下：
设计思路如下：
通过全局流量管理（GTM）将用户就近接入相应的地域。
通过ACK One GitOps应用分发在2个ACK集群中部署应用，实现基于Git仓库的持续一致性部署。
缓存采用多地域高可用方案，更多信息，请参见Tair全球多活。
数据库采用跨地域高可用方案，更多信息，请参见云原生数据库PolarDB MySQL多可用区部署架构。
地域内部署可采用单地域多可用区容灾方案。
多地域单元化多活部署
和前面的多地域容灾方案相比，多地域单元化多活部署方案需要设计分片规则，对应用和数据进行分片，使单元具有面向部分数据分片的完整服务能力，以此实现业务的安全隔离、水平扩展，并能够服务于庞大的用户群体。
在本方案中，一般将多个单元划分为一个中心单元（拥有用户数据）和多个子单元（分片后的详细数据）。该方案的实现需要业务系统支持自定义分流规则、数据拆分等能力，并且需要各单元间进行相互，实施复杂度较高。
方案架构如下：
- 本页导读 （1）