容灾架构
异地应用双活和异地数据双活两种容灾解决方案。本小结分别介绍两种容灾架构的架构特点，并对比两种方案的建设成本、容灾能力及适用场景。
架构特点
异地应用双活
- 应用、中间件两地冗余部署，同时对外提供服务；
- 数据库两地冗余部署，设置其中一个数据中心为主数据中心，两地应用连接主数据中心进行读写，主数据中心数据异步复制至另一个数据中心；
- 实现应用流量多数据中心高可用，备数据中心存在跨地域读写延迟。
异地数据双活
- 应用、中间件两地冗余部署，同时对外提供服务；
- 数据库两地冗余部署，同时提供读写能力，两地应用连接本地的数据库，两地数据中心数据异步双向复制；
- 根据业务需要切分数据分片，业务流量带路由标，按路由规则进行分流，业务数据在指定数据中心闭环，没有跨地域读写延迟。
容灾架构对比
|
对比项 |
异地应用双活 |
异地数据双活 |
|
成本 |
|
|
|
容灾能力 |
说明：具体以数据同步延迟的情况而定 |
说明：具体以数据同步延迟的情况而定 |
|
适用场景 |
|
|
|
限制 |
|
|
|
总结 |
|
|
容灾架构选择建议
您可根据您应用的特点及在性能要求、应用改造程度、建设成本等方面的诉求来选择使用异地应用双活还是异地数据双活，本小结将提供一些场景及该场景下选择哪种架构的建议，供您参考。
|
场景需求 |
建议选择 |
|
期望日常态下两地均提供服务，按比例承接流量，不想改动现在的业务代码。
|
应用双活 |
|
预算有限，期望具备地域级的容灾能力，机房故障时期望可以一键式完成机房故障切换，减少人工介入。
|
应用双活 |
|
业务耦合较深，业务逻辑复杂，数据比较集中。
|
应用双活 |
|
期望能实现用户流量就近访问，如北京的用户访问北京的服务，广州的用户访问广州的服务。
|
数据双活 |
|
期望核心业务拥有较强的容灾能力，一个数据中心发生故障或灾难时，故障范围限制在异常数据中心，不影响其他数据中心，其他数据中心可以正常提供服务。
|
数据双活 |
|
服务读写性能要求很高，无法接受额外的网络延迟。
|
数据双活 |
