衡量容灾系统的主要指标有
- RPO(Recovery Point Object) :灾难发生时允许丢失的数据量
- RTO(Recovery Time Objective) : 系统恢复的时间
- 容灾半径: 生产系统和容灾系统之间的距离
- ROI(Return of Investment): 容灾系统的投入产出比
RPO 是指业务系统所允许的灾难过程中的最大数据丢失量（以时间来度量），这是一个灾备系统所选用的数据复制技术有密切关系的指标，用以衡量灾备方案的数据冗余备份能力。
RTO 是指“将信息系统从灾难造成的故障或瘫痪状态恢复到可正常运行状态，并将其支持的业务功能从灾难造成的不正常状态恢复到可接受状态”所需时间，其中包括备份数据恢复到可用状态所需时间、应用系统切换时间、以及备用网络切换时间等，该指标用以衡量容灾方案的业务恢复能力。例如，灾难发生后半天内便需要恢复，则 RTO 值就是十二小时。
容灾半径是指生产中心和灾备中心之间的直线距离，用以衡量容灾方案所能防御的灾难影响范围。
容灾方案的 ROI 也是用户需要重点关注的，它用以衡量用户投入到容灾系统的资金与从中所获得的收益的比率。
显然，具有零 RTO 、零 RPO 和大容灾半径的灾难恢复方案是用户最期望的，但受系统性能要求、适用技术及成本等方面的约束，这种方案实际上是不大可行的。所以，用户在选择容灾方案时应该综合考虑灾难的发生概率、灾难对数据的破坏力、数据所支撑业务的重要性、适用的技术措施及自身所能承受的成本等多种因素，理性地作出选择。
容灾级别
按照容灾系统对应用系统的保护程度可以分为数据级容灾 、 应用级容灾 和 业务级容灾。
数据级容灾 仅 将生产中心的数据复制到容灾中心，在生产中心出现故障时，仅能实现 存储 系统的接管或是数据的恢复 。容灾 中心的数据可以是本地生产数据的完全复制（ 一般 在同城实现） ， 也可以比生产数据略微落后，但必定是可用的 （一般 在异地实现） ， 而差异的数据 通常 可以通过一些工具（ 如 操作记录、日志等） 可以 手工补回。基于数据容灾 实现 业务恢复的速度 较慢 ，通常情况下 RTO 超过 24 小时， 但是这种 级别 的容灾系统运行维护成本较低。
应用级容灾是 在数据级容灾的基础上，进一步实现应用 可用性 ，确保业务的快速恢复。这就 要求 容灾系统 的 应用不能改变原有业务处理逻辑，是对生产中心系统的基本复制 。因此 ，容灾中心需要建立起一套和本地生产相当的备份环境，包括主机、网络、应用、 IP 等 资源均有配套，当 生产 系统发生灾难时，异地系统可以 提供 完全可用的生产环境。 应用级 容灾的 RTO 通常 在 12 个 小时 以内 ，技术复杂度较高，运行维护的成本也比较高。
业务级容灾 是生产中心 与容灾中心对业务请求同时进行 处理 的容灾方式，能够确保 业务 持续可用。这种 方式 业务 恢复 过程的自动化程度高， RTO 可以 做到 30 分钟 以内 。 但是 这种容灾级别 的 项目 实施难度大， 需要从 应用层对系统进行改造，比较适合流程固定 的 简单业务系统 。 这种 容灾系统 的运行维护成本最高。
同城双活
同城双活是在同城或相近区域内建立两个机房，由于双机房距离比较近，通信线路质量较好，比较容易实现数据的同步复制，保证高度的数据完整性和数据零丢失。同城两个机房各承担一部分流量，一般入口流量完全随机，内部 RPC 调用尽量通过近络由闭环在同机房，相当于两个机房清像部署了两个独立的集群。数据仍然是单点写到主机房数据库，然后实时同步到另外一个机房。
同城双活示意图
路由方案优先级为条件路由 > 就近路由 > 跨机房路由，尽量避免跨机房调用，该方案可以通过对springcloud的注册中心和rpc负载均衡的改造实现。mysql采用MHA部署方案，主从半同步方案保证数据一致。
该方案优势是架构方案较为简单，核心是解决底层数据双活，由于双机房距离近，通信质量好，底层储存例如mysql可以采用同步复制，有效保证双机房数据一致性。劣势是当服务所在的城市或者地区网络整体故障、发生不可抗拒的自然灾害时候有服务故障以及丢失数据风险。
两地三中心
两地三中心是指同城双中心 +异地灾备中心。异地灾备中心是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，数据和服务平时都是冷的，当双中心所在城市或者地区出现异常而都无法对外提供服务的时候，异地灾备中心可以用备份数据进行业务的恢复。
该方案比较同城双活多了一个灾备中心，灾备中心能防范同城双中心同时出现故障时候利用备份数据进行业务的恢复。
异地多活
异地多活指分布在异地的多个站点同时对外提供服务的业务场景。异地多活是高可用架构设计的一种，与传统的灾备设计的最主要区别在于“多活”，即所有站点都是同时在对外提供服务的。
异地多活具体实施面临的问题
切换问题 切换问题不仅仅是灾难发生自动切换到好的机房，还有另外一个问题，就是灾难机房恢复能力后，如何再切换回去，切换回去的数据同步问题又是需要解决的
跨机房流量问题 跨机房的流量是花钱的。所以不是无限大的。控制跨机房消息体大小，越小越好。然而，很多时候要想保证数据同步是一件很耗费流量的事情。跨机房流量有限制，而且不稳定。所以有一种解决方案就是不跨机房。既然不跨机房就要做用户分区，确保每个用户只能访问自己所在的区，这样至少能保证该用户自己的数据的完整。
不是所有业务都适合异地多活 有的业务理论上就无法实现异地多活。典型的有“余额”和“库存”这两个业务。
异地多活的容灾级别无疑是最高的，但投入的成本同样巨大
