多重一致性问题

采用标准化的多活容灾管理产品可以帮助业务减少应用多活的实现成本，克服实现难点，即“多重一致性”问题：

• 流量路由一致性：表现为体验一致性，所有业务请求在预期路径内闭环，请求质量（如响应时间）不随机房分布有明显改变。需要从流量入口开始的每一层技术组件都能够识别、纠错流量，减少额外调用负担（如不合理的跨机房、跨地域调用增加的延迟）。
• 数据读写一致性：表现为结果一致性，所有业务数据在可接受的时间内（由业务感知判断）保持数据正确，没有数据错乱和明显的数据延迟。需要数据层具备跨集群同步的能力，对于跨集群异步同步的场景，还要提供面向业务的容错方案，避免极端场景数据不一致问题。
• 运维管理一致性：表现为操作一致性，所有容灾操作都有标准化操作流程和预期结果。需要容灾平台有通用的数据模型、服务接口和流程模版，帮助业务屏蔽组件管理差异，自动化编排有序的容灾流程。

稳定的恢复预期

度量业务连续性，一般可用两个可用度相关指标来评估：

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

对于传统的非多活管控的应用架构，应用的高可用能力主要取决于组件的高可用能力，例如依赖组件的集群化部署来减少故障导致系统不可用的概率，即通过更长的MTBF来提升业务的SLA等级。

与之相对应的，应用从不可用状态的恢复能力也主要取决于组件的故障恢复能力，即使流量层组件具备一定的调度逃逸功能，由于缺乏与数据层组件的协同，业务数据的一致性也较难得到保障，也就是说业务恢复效率与组件MTTR强相关，且没有明确预期。

在应用多活架构下，“业务恢复”和“故障恢复”是解耦的，在发生故障时，可以通过一体化的切流能力，在保障数据一致性的前提下优先恢复业务，一般是分钟级别的业务恢复时间，在业务恢复的前提下，再进行故障定位和修复。