1. 背景信息
A企业是一个零售行业电商交易平台，业务系统部署在自建IDC机房，存在以下痛点：
- 业务仅在IDC单机房部署，缺少容灾能力。
- IDC容量不足，物理机器升级替换周期长，不足以支撑业务的快速发展。
业务在快速发展过程中，多次遇到容量不足以及故障问题引起了公司高层的重视，因此决定进行容灾能力建设。由于自建IDC是公司已有资产且稳定使用多年，同时不希望过度依赖于云，因此期望建立IDC+云的混合云形态容灾架构。
2. A企业当前的应用部署架构
电商交易平台包含的应用：
- frontend：Web应用，负责和用户交互。
- cartservice：购物车应用，提供购物车添加、存储和查询服务。
- productservice：商品应用，提供商品、库存服务。
技术栈：
- SpringBoot。
- RPC框架：SpringCloud、Dubbo，注册中心使用自建的Nacos、ZooKeeper。
- 数据库：Redis和MySQL。
3. 混合云容灾目标
A企业业务容灾的需求如下：
| 需求 | 说明 |
| 云上云下互容灾，切换RTO为分钟级。 | 期望云上云下相互容灾，继续发挥IDC的价值，且不100%依赖于云。面对IDC或云故障场景，关键时刻要敢切换、能切换，且切换RTO要求小于10分钟。 |
| 无数据一致性风险。 | 云上云下的两个数据中心数据强一致，日常态和容灾切换过程中都要避免存在脏写等数据一致性风险。 |
| 一站式管控。 | 业务容灾涉及的技术栈框架和云产品，需要统一管控、统一运维、统一切换，操作收敛在一站式管控平台，方便故障场景快速白屏化操作，自动化执行。 |
| 实施周期短，改造成本低。 | 业务存在多个产品线，依赖关系复杂、调用链路长，且处于高速发展频繁迭代时期，期望容灾建设不会给业务研发团队带来改造负担。 |
4. 建设难点
建立IDC+云的混合云形态容灾架构难点如下：
| 难点 | 说明 |
| 流量管理难度高 |
|
| 容灾切换数据质量保障难 | 容灾切换过程中，可能因数据同步延迟导致读到旧数据，以及切换规则推送到分布式应用节点时间不一致等原因可能造成云上云下数据库同时读写而出现脏写的问题，整个切换过程数据质量保障是关键点及难点。 |
| 无业务代码侵入难 | 要实现Redis、MySQL容灾切换能力，通常需要业务应用配合改造，对业务代码侵入大。 |
5. 解决方案
结合业务容灾需求和混合云IDC+云形态的特点，采用应用双活架构能够较好的满足业务容灾诉求。
应用双活架构
架构简图：
限制：业务需要能接受两地距离带来的网络延迟。
架构规范：
- 选择离IDC物理距离≤200 km的云上地域（Region），网络延迟较低（约5~7 ms）。
- 应用、中间件云上云下冗余对称部署，同时对外提供服务（应用双活）。
- 数据库异地主备，异步复制备份。应用读写同一数据中心的数据库，避免考虑一致性问题。
解决方案
架构简图：
解决方案：
- 应用流量双活：
- 业务应用云上云下对称部署，并基于MSHA接入层集群，来承接入口HTTP/HTTPS流量，按照比例或精准路由规则云上云下分流。
- 多活控制台提供MSFE集群界面白屏化的部署、扩缩容、监控等常规运维能力，以及应对故障场景的分钟级切流能力。
- 服务互通和同单元优先调用：
- 业务应用需要按业务产品线分批上云，过程中存在下游应用仅IDC部署的情况。利用MSHA注册中心同步功能，可实现云上云下服务互通，助力业务上云。
- 同时基于MSHA-Agent的切面能力，在Dubbo/SpringCloud服务调用时，Consumer优先调用同单元内的Provider，从而避免跨机房调用带来的网络延迟，减小业务请求RT。
- 数据同步及数据库连接切换：
- 数据库异地主备部署，云上云下应用日常态均读写云上Redis和RDS数据库，无需考虑数据一致性问题。MSHA控制台通过集成DTS同步组件，支持云上云下的数据同步（异步复制）。
- 同时基于MSHA-Agent切面能力，具备应用数据库访问连接的切换能力，云上Redis或RDS故障则可将读写访问连接切换到IDC内的Redis或MySQL，反之亦然。切换过程中还具备禁写保护能力，避免产生读到旧数据以及脏写等数据质量问题。
- 一站式管控及无业务代码侵入
- MSHA控制台，支持HTTP、数据库访问流量的统一管控、统一切换，操作收敛在一站式管控平台，方便故障场景快速白屏化操作，自动化执行。
- 同时针对业务应用MSHA提供了Agent接入方式，无需业务代码改造即可获得相关容灾切换能力。
6. 改造内容
A企业建立IDC+云的混合云形态容灾架构，所需改造的内容如下：
| 改造点 | 说明 |
| 应用上云 | 选择跟自建IDC较近的阿里云地域，云上完全冗余的部署一套应用、中间件和数据库，以便搭建云上云下双活容灾架构。在这个Demo案例中，选择杭州地域（Region）作为容灾单元。 |
| 网络打通 | 接入CEN云企业网，实现云上云下网络互通。具体操作，请参见多接入方式构建企业级混合云。 |
| 接入集群部署和配置 |
|
| 应用 |
|
| 中间件和数据库 |
改造后的应用部署架构：
- 日常场景：IDC+云上同时承担业务流量（即应用双活）。
- 访问电商Demo首页，查看实际流量调用链：概率性的访问到北京或杭州单元，均读写北京单元内的数据库。
- 电商Demo首页图：
- 均读写北京单元内的数据库架构简图：
- 电商Demo首页图：
7. 容灾能力
- RPO：≤1分钟（依赖于DTS同步性能）。
- RTO：≤1分钟（依赖于DTS同步延迟，MSHA组件实现秒级切换。整体RTO≤1分钟）。
8. 容灾能力验证
基于MSHA完成应用双活架构建设后，还需验证业务容灾能力是否符合预期。接下来将制造真实的故障，来验证容灾恢复能力。
步骤一：演练准备
- 登录AHAS控制台。
- 在控制台左侧导航栏中选择多活容灾。
- 在左侧导航栏单击监控大盘，并在顶部选择目标命名空间，查看各项监控指标。
说明 演练前，基于MSHA流量监控或其他监控产品，确定业务稳态的监控指标（如日常情况RT≤200ms，错误率<1%），以便在故障发生时判断故障影响面以及在故障恢复后判断业务的实际恢复情况。
步骤二：应用故障注入
这里使用阿里云故障演练产品，对阿里云-北京地域的商品应用注入故障。
- 登录AHAS控制台。
- 在左侧导航栏选择故障演练 > 我的空间，并在顶部选择地域。
- 在我的空间页面搜索配置好的演练（50%概率网络丢包），然后在该演练名称对应的操作列单击演练。在弹出的对话框中单击确认。
故障注入成功后，打开电商首页或进行下单，有概率出现访问异常，则符合预期。
步骤三：切流恢复
在北京单元的商品应用故障的情况下，可以通过MSHA切流功能，将云上入口流量切0，快速恢复业务。
预期效果：100%流量切换到杭州单元后，业务完全恢复，不受北京单元的故障影响。
- 登录AHAS控制台。
- 在控制台左侧导航栏中选择多活容灾。
- 在左侧导航栏选择切流 > 异地应用双活切流，并在顶部选择地域。
- 在异地应用双活切流页面单击切流，然后在第①步规则调整区域的北京单元右侧单击一键切流，并单击生成预览，将北京单元的应用流量一键切零。
- 单击第②步的执行预检查，然后单击第③步切流检查区域的确认，开始切流。
若 切流任务运行中页面的 当前状态显示 切流完成，表示切流已成功。
- 刷新电商Demo首页，多次访问均能正常展示，则符合预期。
查看实际流量调用链：流量始终访问到杭州单元，读写北京单元内的数据库。
步骤四：数据库故障注入
从上面调用链可以看出，杭州单元内的应用仍然访问的是北京单元的Redis、MySQL数据库。以同样的方式执行步骤二对北京单元的Redis、MySQL数据库注入故障，制造数据库故障场景。
故障注入成功后，打开电商首页或进行下单始终访问异常，则符合预期。
步骤五：切换数据库进行恢复
在北京单元的数据库故障的情况下，可以通过MSHA数据库切换功能，将应用访问的Redis或MySQL的连接切换至杭州单元的数据库（切换过程中会等待数据同步追平，期间会短暂禁写）。
预期效果：应用连接的数据库切换到杭州后，业务完全恢复，不受北京单元的故障影响。
- 登录AHAS控制台。
- 在控制台左侧导航栏中选择多活容灾。
- 在左侧导航栏选择异地应用双活 > 数据层配置。
- 在数据保护规则列表中，通过搜索查询商品、订单、购物车数据库，依次单击主备切换。
商品数据库：
购物车数据库：
- 单击主备切换后，进入预检查结果页面，确认各检查项状态正常后，然后单击确认执行，在主备切换详情页面自动执行切换流程。
在主备切换详情页面，可以查看切换进度和切换结果，当任务进度为100%，表示切换完成。主备切换完成后的结果如下图所示。
商品、订单、购物车数据库都完成主备切换后，多次访问电商Demo首页或进行下单，发现均已正常，主备切换后业务功能完全恢复，则符合预期。
通过MSHA多活容灾助力企业进行混合云应用双活容灾建设的实践案例，给出了容灾架构建设实践方法，同时利用Chaos故障演练产品注入真实故障，来验证故障场景业务容灾能力是否符合预期。若您在使用过程中有任何疑问，欢迎您搜索钉钉群号“31623894”加入“多活容灾（MSHA）交流群”获取帮助。