异地多活架构的3种模式

业务定制型异地多活

按照业务的优先级进行排序，优先保证核心业务异地多活

基于核心业务的流程和数据，设计定制化的异地多活架构

优点

对基础设施无强要求，例如机房部署、存储系统、时延等，一般部署在远距离的两个城市，可以支持区域级别故障处理

缺点

1. 不通用，每个业务都需要单独来做异地多活，业务需要改造
2. 难扩展，核心业务如果有重大变化，异地多活方案要重新设计

业务通用型异地多活

通过配套服务来支持异地多活，无需按照业务优先级排序来挑选某些业务实现异地多活，只需要判断业务是否能异地多活

优点

1. 对硬件基础设施无强要求，例如机房部署、存储系统、时延等，一般部署在远距离的两个城市，可以支持区域级别故障处理
2. 业务基本不用改造，只需判断业务是否支持 BASE，支持就可以异地多活，不支持就单点部署

缺点

1. 配套服务复杂，包括流量调度、容灾切换、建站平台、配置管理等
2. 存在全局单点业务，例如库存、卖家等相关业务
3. 机房距离较远的时候，RTO 比较大，可能达到分钟级

存储通用型异地多活

采用本身已经支持分布式一致性的存储系统，架构天然支持异地多活

优点

架构天然就支持异地多活，业务除了切换存储系统外，其它基本不用改造

缺点

1. 需要分布式一致性的存储系统支持，目前这样的存储系统可选不多，例如 ZooKeeper、etcd、OceanBase
2. 对机房部署有强要求，如果要实现异地多活，只能采用近邻部署

异地多活架构模式对比