异地多活架构的3种模式

业务定制型异地多活

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

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

优点

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

缺点

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

业务通用型异地多活

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

优点

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

缺点

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

存储通用型异地多活

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

优点

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

缺点

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

异地多活架构模式对比

	应对机房级别灾难	应对城市级别灾难	应对区域级别灾难	是否通用	配套服务	硬件成本	应用建议
业务定制型	是	是	是	否	低，只需要很少配套服务	低，无特别要求	中小公司 中小业务
业务通用型	是	是	是	是	高，强大的配套服务	低，无特别要求	大公司，业务无强一致性，例如视频、资讯、微博、社交类业务
存储通用型	是	是	否，要求近邻部署	是	低，只需要很少配套服务	高，对机房数量和时延有强要求	大公司，业务有强一致性要求，例如交易、支付、金融类业务