产品定义

应用容灾多活包含架构加管控的解决方案，提供引导式的应用架构改造接入和一站式的云产品协同管理，实现应用异地集群间日常态的流量分发多活以及容灾态的数据一致性保障，助力企业的容灾稳定性建设，提升客户应用的业务连续性。

容灾的不同等级

容灾的基本方式，是在生产站点以外建立冗余站点，灾难发生后，冗余站点可以接管用户正常的业务，达到业务不间断的目的。按照容灾系统对应用系统的保护程度可以分为数据级容灾、应用级容灾和业务级容灾。

• 数据级容灾：仅将生产中心的数据复制到容灾中心，在生产中心出现故障时，仅能实现存储系统的接管或数据的恢复。基于数据级容灾实现业务恢复的速度较慢，需要在容灾站点恢复数据实例和部署应用，通常情况下RTO在天级别。

• 应用级容灾：在数据级容灾的基础上，增加对生产中心系统的基本复制，容灾中心建立起一套和本地生产环境相当的备份环境，包括主机、网络、应用等资源。当生产系统发生灾难时，异地系统可以提供完全可用的生产环境，应用级容灾的RTO通常在小时级别。

• 业务级容灾：容灾中心具备业务系统的完全复制，生产中心与容灾中心对业务请求同时进行处理，故障时只需切换业务流量，能够确保业务持续可用。采用这种方式，业务恢复过程的自动化程度高，RTO可以做到分钟级别。

灾备容灾建立在数据级和应用级容灾基础之上，在异地冗余一套应用系统的部分或全部备份，平时不对外提供服务，根据备份时效和颗粒度不同，业务在灾难发生时按照约定的时间和版本恢复运行。

多活容灾是业务级容灾，应用系统分布在多个站点同时对外提供服务，与灾备模式相比拥有更高的资源利用率和系统扩展性，当灾难发生时，多活系统可以实现分钟级业务流量切换，用户甚至感受不到灾难发生。

容灾的效果评估

容灾系统的建设目标是为了保障灾难发生时业务不中断，度量业务连续性可以采用两个可用度相关指标来评估：

• MTBF（Mean Time Between Failure）：指系统在两次故障之间的平均时间。

• MTTR（Mean Time To Repair）：指系统从故障发生到故障修复完成所需的平均时间。

应用从单点向集群发展，对局部故障的消纳能力有了长足的进步，但灾难是不可避免的，容灾的重点不在于降低系统故障发生的概率，即更长的MTBF，而在于提升系统故障恢复的效率，即更短的MTTR。

容灾恢复的质量不单指尽可能快地恢复业务运行，也包括恢复尽可能多的业务数据，通过RTO和RPO来衡量：

• RTO（Recovery Time Objective）：恢复时间目标，指灾难发生后，业务系统从停止服务到恢复服务的时间要求，也即能够容忍服务停止的最长时间。

• RPO（Recovery Point Objective）：恢复点目标，指灾难发生后，业务数据和状态能够保留的时间要求，也即能够容忍数据丢失的最大范围。

从单纯的数据备份，到应用灾备，再到应用多活，容灾等级从数据级发展到应用级，最后到业务级，要求越来越短的RTO和越来越小的RPO。

但容灾系统的设计受多方面因素影响，比如应用运行现状、业务可选的技术栈、用户能够投入的技术和经济开销等，这些都将构成容灾建设的成本，决定用户可选择的容灾架构。

容灾解决的问题

传统的灾备容灾在实际落地中会面临一些问题：

• 如果选择成本优先策略，灾备中心日常只保留必要的冗余数据，灾难接管时再逐步恢复数据实例和业务系统，操作成本高，恢复时间无法预期，无法保障RTO；

• 如果选择效率优先策略，灾备中心日常保持完整的业务应用复刻，由于灾备中心平时不提供服务，整个灾备资源处于闲置状态，成本浪费比较严重；

• 因为灾备中心平时不提供服务，关键时刻不能保证灾备中心能否正确接管业务，灾难真正发生时不一定敢切。

应用容灾多活是应用高可用服务下的多活容灾解决方案，在架构上比灾备容灾更具优势，能突破单地域资源瓶颈，拥有更高的资源利用率和系统扩展性，具备如下产品优势：

• 一站接入管控：应用分层管理，接入层、服务层、数据层等统一纳管调度；

• 快速恢复预期：确定的流程编排，一键容灾切换，分钟级业务恢复能力；

• 高效运维监控：组件协同管理，全链路监控告警，容灾运维简单高效。