前言
越来越多的企业在数字化转型和上云进程中选择混合云的形态（云+自建IDC或云+其他厂商云）来进行容灾建设，一方面不会过度依赖单一云厂商，另一方面还能充分利用已有的线下IDC资源。
MSHA云原生多活容灾解决方案[1]，也发布了混合云多活容灾产品能力。本文会通过一个业务Demo案例，介绍混合云容灾建设的难点，以及如何基于MSHA来快速搭建应用双活架构并具备分钟级业务恢复能力。
业务混合云容灾实践
业务背景信息
A企业是一个零售行业电商交易平台，业务系统部署在自建IDC机房，存在以下痛点：
业务仅在IDC单机房部署，缺少容灾能力。IDC容量不足，物理机器升级替换周期长，不足以支撑业务的快速发展。
业务在快速发展过程中，多次遇到的容量不足以及故障问题引起了公司高层的重视，决心进行容灾能力建设。由于自建IDC是公司已有资产且稳定使用多年，同时不希望过度依赖于云，因此期望建立IDC+云的混合云形态容灾架构。
当前应用部署架构
电商交易平台包含的应用：
frontend：Web应用，负责和用户交互。cartservice：购物车应用，提供购物车添加、存储和查询服务。productservice：商品应用，提供商品、库存服务。
技术栈：
SpringBoot。RPC框架：SpringCloud、Dubbo，注册中心使用自建的Nacos、Zookeeper。数据库Redis和MySQL。
混合云容灾目标
业务容灾需求归纳如下：
云上云下互容灾，切换RTO为分钟级。期望云上云下相互容灾，继续发挥IDC的价值，且不%依赖于云。面对IDC或云故障场景，关键时刻要敢切换、能切换，且切换RTO要求小于10分钟。无数据一致性风险。云上云下的两个数据中心数据强一致，日常态和容灾切换过程中都要避免存在脏写等数据一致性风险。一站式管控。业务容灾涉及的技术栈框架和云产品，需要统一管控、统一运维、统一切换，操作收敛在一站式管控平台，方便故障场景快速白屏化操作，自动化执行。实施周期短，改造成本低。业务存在多个产品线，依赖关系复杂、调用链路长，且处于高速发展频繁迭代时期，期望容灾建设不会给业务研发团队带来改造负担。
建设难点
流量管理难度高若采用DNS将流量按权重解析到云上和云下，存在修改DNS解析生效时间长的问题（通常为十分钟或小时级，参见DNS解析生效时间FAQ[2]），不能满足容灾切换小于10分钟的要求。业务应用所依赖的Redis和MySQL，IDC内采用开源自建而云上直接使用云产品，要实现开源自建+云产品的容灾切换能力难。容灾切换数据质量保障难容灾切换过程中，可能因数据同步延迟导致读到旧数据，以及切换规则推送到分布式应用节点时间不一致等原因可能造成云上云下数据库同时读写而出现脏写的问题，整个切换过程数据质量保障是个关键点，同时也是难点。无业务代码侵入难要实现Redis、MySQL容灾切换能力，通常需要业务应用配合改造，对业务代码侵入大。
解决方案
结合业务容灾需求和混合云IDC+云形态的特点，采用应用双活架构能够较好的满足业务容灾诉求。
应用双活架构
架构简图：
架构规范：
选择离IDC物理距离=km的云上Region，网络延迟较低（约5~7ms）。应用、中间件云上云下冗余对称部署，同时对外提供服务（应用双活）。数据库异地主备，异步复制备份。应用读写同一数据中心的数据库，避免考虑一致性问题。
详细方案
应用流量双活
业务应用云上云下对称部署，并基于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接入方式，无需业务代码改造即可获得相关容灾切换能力。
改造内容
应用上云选择跟自建IDC较近的阿里云地域，云上完全冗余的部署一套应用、中间件和数据库，以便搭建云上云下双活容灾架构。在这个Demo案例中，选择杭州Region作为容灾单元。网络打通：接入CEN云企业网，实现云上云下网络互通（详见多接入方式构建企业级混合云文档[3]）。接入集群部署和配置：云上云下部署MSHA接入层集群（MSFE），上挂SLB用于公网接入以及MSFE集群的负载均衡（参见使用文档[4]）。录入域名、URI和后端应用地址，从而具备云上云下分流和分钟级切流能力（参见使用文档[5]）。应用：云上分批部署业务应用。JAVA应用安装MSHA-Agent，并使用Nacos作为管控命令下发通道，从而具备微服务同单元优先调用以及数据库访问连接切换能力（参见使用文档[6]）。中间件和数据库：云上部署MSE托管ZK/Nacos注册中心、云数据库Redis和RDS，建议使用跨可用区部署高可用版本，具备同城双活容灾能力。若存在某应用仅IDC部署的情况，需要配置注册中心的服务同步（参见使用文档[7]）。配置云数据库Redis/RDS和自建Redis/MySQL的数据同步（参见使用文档[8]）。
改造后的应用部署架构
日常场景：IDC+云上同时承担业务流量--应用双活
访问电商Demo首页，查看实际流量调用链：概率性的访问到北京或杭州单元，均读写北京单元内的数据库。
容灾能力
RPO：=1min（依赖于DTS同步性能）RTO：=1min（依赖于DTS同步延迟，MSHA组件实现秒级切换。整体RTO=1min）
容灾能力验证
基于MSHA完成应用双活架构建设后，还需验证业务容灾能力是否符合预期。接下来将制造真实的故障，来验证容灾恢复能力。
7.1演练准备
进入MSHA控制台，在左侧菜单栏选择监控大盘。页面顶部，下拉选择切换到实际使用的命名空间。查看页面中的各项监控指标。
说明：演练前，基于MSHA流量监控或其他监控产品，确定业务稳态的监控指标（如日常情况RT=ms，错误率1%），以便在故障发生时判断故障影响面以及在故障恢复后判断业务的实际恢复情况。
7.2应用故障注入
这里我们使用阿里云故障演练产品，对阿里云-北京的商品应用注入故障。
进入Chaos故障演练产品控制台[9]，顶部选择切换到相应地域，左侧导航栏选择我的空间。在我的空间选择配置好的演练（50%概率网络丢包），然后单击执行演练。
故障注入成功后，打开电商首页或进行下单，有概率出现访问异常，符合预期。
7.3切流恢复
在北京单元的商品应用故障的情况下，可以通过MSHA切流功能，将云上入口流量切0，快速恢复业务。
预期
%流量切换到杭州单元后，业务完全恢复，不受北京单元的故障影响。
切流操作
1.进入MSHA控制台，在左侧导航栏选择切流异地应用双活切流。
2.在切流页面，对北京单元点击一键切零。
3.单击执行预检查，在切流检查区域，单击确认，开始切流。
4.在切流任务页面的当前状态显示切流完成，表示切流已成功。
5.刷新电商Demo首页，多次访问均能正常展示，符合预期。查看实际流量调用链：流量始终访问到杭州单元，读写北京单元内的数据库。
7.4数据库故障注入
从上面调用链可以看出，杭州单元内的应用仍然访问的是北京单元的Redis、MySQL数据库。我们继续使用Chaos故障演练[10]产品对北京单元的Redis、MySQL数据库注入故障，制造数据库故障场景。
故障注入成功后，打开电商首页或进行下单始终访问异常，符合预期。
7.5切换数据库进行恢复
在北京单元的数据库故障的情况下，可以通过MSHA数据库切换功能，将应用访问的Redis/MySQL的连接切换至杭州单元的数据库（切换过程中会等待数据同步追平，期间会短暂禁写）。
预期
应用连接的数据库切换到杭州后，业务完全恢复，不受北京单元的故障影响。
切流操作
1.进入MSHA控制台，在左侧导航栏选择异地应用双活数据层配置。
2.在数据保护规则列表中，找到商品、订单、购物车数据库，逐个点击主备切换。
3.点击主备切换后，会进入预检查页面，确认各检查项状态正常后，点击在确认执行，则进入切换详情页，并自动执行切换流程。
4.主备切换详情页，可以看到切换进度和切换结果，任务进度%后，表示切换完成。
5.商品、订单、购物车数据库都主备切换完成后。多次访问电商Demo首页或进行下单，发现均已正常，主备切换后业务功能完全恢复，符合预期。
总结
在本篇文章中，我们介绍了MSHA多活容灾助力企业进行混合云应用双活容灾建设的实践案例，给出了容灾架构建设实践方法，同时利用Chaos故障演练产品注入真实故障，来验证故障场景业务容灾能力是否符合预期。
相关阅读
[1]MSHA云原生多活容灾解决方案