什么时候可以选用应用双活架构？
应用双活架构采用数据主备集群模式，优点是实现简单，业务改造成本低，不需要过多考虑多中心数据读写冲突问题，流量层和应用层常态化跨中心多活，数据层通过容灾主备切换实现高可用。
推荐业务场景包括：
- 业务数据集中化，无法拆分。
- 业务数据拆分成本高，应用期望少改造或零改造。
- 数据中心距离较近，异地数据读写延迟可接受（建议物理距离≤100km，网络延迟≤10ms）。
什么时候可以选用数据双活架构？
数据双活架构采用基于业务数据分片的单元化模式，不受数据中心距离限制，流量在单元内闭环，单元故障影响不外溢。相比异地应用双活方案业务体验更好、故障爆炸半径更小、容灾切换更平滑，但应用改造成本更高，要求业务数据拆分、流量带标和标记传递。
推荐业务场景包括：
- 单个中心数据负载过高，需要水平拆分（要求业务数据能够拆分）。
- 数据中心距离较远，异地调用成本过高。
- 技术投入和技术栈能够支撑应用改造。
多活容灾是否一定要进行业务改造？
不一定。在选用应用双活架构时，应用可以不做改造，只需要引入应用容灾多活的探针即可。
数据双活架构的数据分区与流量封闭需要对业务应用进行必要的改造，一般来说有如下考虑和实施：
- 如要求服务调用分区闭环，需进行业务垂直拆分和微服务改造。
- 如要求数据访问分区闭环，需进行数据水平拆分，确定分片键。
- 如要求流量调度分区闭环，需进行入口流量带标以及路由标传递改造。
多活容灾是否只要做好入口流量分发和底层数据同步？
否。入口流量分发和底层数据同步是实现多活能力的重要步骤，但并不能完全保证系统具备多活能力。
要具备完整的多活能力，首先做好架构规划与演进，其次要有配套的管控能力，包括集中管理、流量控制、数据同步、数据保护等。
如何保障业务在多活场景下的数据一致性？
默认使用异步复制和最终一致性模型，通过流量纠错和禁写保护避免脏写，有更高要求建议使用分布式数据库。
微服务是如何实现跨集群发现的？
微服务通过注册中心数据同步来实现跨集群服务发现，服务调用时根据路由规则计算路由命中来选择跨单元或跨站点调用。
微服务在多活场景该如何处理？
尽可能单元内自封闭，若无法自封闭，可配置HTTP/DUBBO的解析规则对微服务进行打标，流量通过路由规则计算后实现跨单元调用。
消息在多活场景该如何处理？
生产侧在消息的header或body打标，消费侧根据路由规则进行过滤或接管，消息在站点间同步，避免数据丢失。
缓存在多活场景该如何处理？
应用读写本地缓存集群，缓存本身不建议同步，本地数据中心的缓存不包含其他中心的数据，当流量切换到新中心时可通过数据库重建缓存。
任务调度在多活场景该如何处理？
您可以考虑以下两个方案：
- 数据双活：2个站点均开启定时任务，捞取全量数据，过滤掉非本单元的数据后再执行。
- 应用双活：2个站点均开启定时任务，通过配置中心开关控制任务执行的主、备站点角色，由主站点执行全量定时任务。
多活数据面性能指标如何？
- 应用容灾多活协同其他云产品，用户可以通过查阅天翼云官方文档，了解使用到的产品组件指定规格实例的性能指标。
- 对于引入多活探针的性能变化，同城场景RT基本没增长，异地场景RT约有1~10ms增长，取决于具体业务与物理距离。
业务如何尽可能平滑地过渡到双活架构？
业务应用从原有架构向双活扩展时，应以标准化的多环境多步骤的流程进行渐进式迭代，尽可能避免产生大范围影响，从而实现平滑过渡。
多环境 ：
- 应用发布按标准的日常、预发、灰度、生产等流程进行上线。
多步骤 ：
- 分析业务现状，明确流量、数据和代码改造点，包括服务拆分、数据拆分、流量染色等。
- 规划物理架构，开通目标区域、可用区、网络和中间件等资源。
- 完成架构升级，根据不同改造点兼容性，业务原集群多版本迭代更新。
- 部署双活集群，对新集群进行复影流量、灰度流量等业务正确性验证。
- 应用分层切换，微服务、消息、数据库等组件切换多活规则。
