介绍：本文将通过一个业务demo案例介绍混合云容灾建设的难点，以及如何快速搭建基于MSHA的应用双活架构具有分钟级业务恢复能力。作者：袁志前言越来越多的企业在数字化转型和上云过程中，选择混合云（云+自建IDC或云+其他厂商云）的形式进行容灾建设。一方面，他们不会过多依赖单一的云厂商，另一方面，也可以充分利用现有的线下IDC资源。MSHA云原生多活灾备解决方案[1]也发布了混合云多活灾备产品能力。本文将通过一个业务demo案例介绍混合云容灾建设的难点，以及如何快速搭建基于MSHA的应用双活架构，并具备分钟级的业务恢复能力。业务混合云容灾实践业务背景资料企业A是一家零售行业电商交易平台。业务系统部署在自建IDC机房。存在以下痛点：业务仅部署在单个IDC机房，缺乏容灾能力。IDC容量不足，物理机升级换代周期长，不足以支撑业务的快速发展。在业务快速发展的过程中，容量不足和多次遇到的故障引起了公司高层的重视，并下定决心建设容灾能力。由于自建的IDC是公司的现有资产，已经稳定使用多年，不想过多依赖云，所以希望建立IDC+云的混合云容灾架构。当前应用部署架构电子商务交易平台中包含的应用：前端：负责与用户交互的Web应用。cartservice：购物车应用，提供购物车添加、存储和查询服务。productservice：商品应用，提供商品和库存服务。技术栈：SpringBoot。RPC框架：SpringCloud、Dubbo，注册中心使用自建Nacos、Zookeeper。数据库Redis和MySQL。混合云容灾目标业务的容灾需求总结如下：云与云之间互容容灾，切换RTO为分钟级。预计云上云下互容灾备将继续发挥IDC的价值，不会100%依赖云。面对IDC或云故障场景，要敢于切换，关键时刻能够切换，切换RTO要求小于10分钟。没有数据一致性风险。云上云下两个数据中心的数据强一致，常态和容灾切换过程中要避免脏写等数据一致性风险。一站式管控。业务容灾涉及的技术栈框架和云产品需要统一管控、统一运维、统一切换。操作汇聚在一站式管控平台，实现快速白屏操作，故障场景自动执行。实施周期短，改造成本低。业务产品线多，依赖关系复杂，调用链长，处于快速发展和频繁迭代期。希望灾备建设不要给业务研发团队带来转型负担。建设难点流量管理难如果使用DNS根据权重解析出入云流量，会存在修改DNS解析需要很长时间才能生效的问题（一般十几分钟或者几小时），见DNS解析有效时间FAQ[2])，无法满足容灾切换时间小于10分钟的要求。业务应用依赖的Redis和MySQL，使用IDC开源自建，直接使用云上的云产品。开源自建+云产品的容灾切换能力难以实现。容灾切换数据质量保障难。容灾切换过程中，由于数据同步延迟，可能会读取到旧数据，切换规则推送到分布式应用节点的时间不一致。至于写的问题，整个切换过程中的数据质量保证是重点，也是难点。无业务代码入侵难实现Redis和MySQL的容灾切换能力，业务应用通常需要配合改造，对业务代码的入侵较大。该方案结合业务容灾需求和混合云IDC+云形态的特点，采用应用双活架构，更好地满足业务容灾需求。应用双活架构图：架构说明：选择云上与IDC物理距离<=200km，网络延迟低（5~7ms左右）的区域。应用和中间件云内外冗余对称部署，同时对外提供服务（应用双活）。数据库异地主动备份，异步复制备份。应用在同一个数据中心读写数据库，避免了一致性问题的考虑。详细方案采用流量双活业务应用，云上云下对称部署，基于MSHA接入层集群，承载入口HTTP/HTTPS流量，划分云上云下流量根据比例或精确的路由规则。多活控制台提供白屏部署、扩缩容、MSFE集群接口监控等日常运维能力，以及针对故障场景的分钟级流量切换能力。同单元内业务应用的业务互通和优先调用，需要按照业务产品线分批次上云。在此过程中，下游应用仅由IDC部署。利用MSHA注册中心的同步功能，实现云内外服务互通，实现业务上云。同时，基于MSHA-Agent的切面能力，在调用Dubbo/SpringCloud服务时，Consumers优先调用同一单元内的Provider，从而避免跨机房调用带来的网络延迟，降低服务请求RT。数据同步&数据库连接切换数据库远程主备部署，云上云下应用可以日常状态下读写云上的Redis和RDS数据库，无需考虑数据一致性问题。MSHA控制台通过集成DTS同步组件，支持云端和云端数据同步（异步复制）。同时基于MSHA-Agent切面能力，具备切换应用数据库访问连接的能力。如果云上的Redis或RDS出现故障，读写访问连接可以切换到IDC中的Redis或MySQL，反之亦然。它还具有在切换过程中禁止写保护的能力，以避免读取旧数据和脏写等数据质量问题。一站式管控&业务代码不侵入MSHA控制台，支持HTTP和数据库访问流量的统一管控和统一切换，操作汇聚在一站式管控平台，方便快速白屏运行，自动化执行故障场景。同时为业务应用MSHA提供Agent接入方式，无需修改业务代码即可获得相关的容灾切换能力。改造内容，为云应用选择距离自建IDC较近的阿里云地域，在云上部署一套完全冗余的应用、中间件、数据库，构建双活容灾云上和云外的恢复架构。本次demo案例选择杭州大区作为容灾单位。网络连接：连接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控制台，在左侧菜单栏选择MonitorDashboard。在页面顶部，选择下拉列表以切换到实际使用的命名空间。查看页面的监控指标。注：演练前，基于MSHA流量监控或其他监控产品，确定业务稳定性监控指标（如日常情况下RT<=200ms，错误率<1%），判断故障影响当发生故障并从故障中恢复时再判断业务实际恢复情况。7.2应用故障注入这里我们使用阿里云故障演练产品对阿里云-北京商品应用进行故障注入。进入混沌断层演练产品控制台[9]，在顶部选择切换到相应区域，在左侧导航栏中选择我的空间。在我的空间中选择已配置的演练（网络丢包概率为50%），点击执行演练。故障注入成功后，打开电商首页或下单时，可能会出现访问异常，符合预期。7.3流量切换恢复当北京单位出现产品应用故障时，可利用MSHA流量切换功能将云端入口流量切断为0，快速恢复业务。预计100%流量切换到杭州单元后，业务将全面恢复，不会受到北京单元故障的影响。切换操作进入MSHA控制台，在左侧导航栏选择码流切换>远程应用双活切换。在流量切换页面，为北京单位点击一键切换归零。单击“ExecutePre-Check”，在流量切断检查区域单击“OK”，开始流量切断。当前切换任务页面当前状态显示切换完成，说明切换成功。刷新电商Demo首页，多次访问后可以正常显示，符合预期。查看实际流量调用链：流量始终访问杭州单元，在北京单元读写数据库。7.4数据库故障注入从上面的调用链可以看出，杭州单位的应用仍然访问北京单位的Redis和MySQL数据库。我们继续使用Chaos故障演练[10]产品对北京单位的Redis和MySQL数据库进行故障注入，创建数据库故障场景。故障注入成功后，打开电商首页或下单总是访问异常，符合预期。7.5切换数据库恢复北京单元数据库出现故障时，可以使用MSHA数据库切换功能，将应用访问的Redis/MySQL连接切换到杭州单元数据库（切换过程中，会等待待同步的数据。临时禁止写入）。预计应用连接的数据库切换到杭州后，业务将全面恢复，不会受到北京单位故障的影响。进入MSHA控制台进行流切换操作，在左侧导航栏选择“远程应用双活>数据层配置”。2.在数据保护规则列表中，找到商品、订单、购物车数据库，一一点击主备切换。点击主备切换后，进入预检页面。确认各项检查项状态正常后，点击确认并执行，进入倒换详情页面，自动执行倒换流程。在主备倒换详情页面，可以看到倒换的进度和结果。当任务进度达到100%时，切换完成。商品数据库、订单数据库、购物车数据库主备倒换完成后。多次访问电商Demo首页或下单，发现正常。主备倒换后，业务功能全面恢复，符合预期。总结在本文中，我们介绍了MSHA多活灾备协助企业构建混合云应用双活灾备的实践案例，并给出了灾备架构构建的实践方法。同时，我们使用Chaos故障钻取产品来注入真实的故障。验证业务容灾能力在故障场景下是否符合预期。原文链接本文为阿里云原创内容，未经许可不得转载。
