作者：远跖

前言

Cloud Native

业务混合云容灾实践

Cloud Native

• 业务仅在 IDC 单机房部署，缺少容灾能力。

• IDC 容量不足，物理机器升级替换周期长，不足以支撑业务的快速发展。

当前应用部署架构

• frontend：Web 应用，负责和用户交互。

• cartservice：购物车应用，提供购物车添加、存储和查询服务。

• productservice：商品应用，提供商品、库存服务。

• SpringBoot。

• RPC 框架：SpringCloud、Dubbo，注册中心使用自建的 Nacos、Zookeeper。

• 数据库 Redis 和 MySQL。

  

  2 混合云容灾目标

  
  

  业务容灾需求归纳如下：
  
  • 云上云下互容灾，切换 RTO 为分钟级。期望云上云下相互容灾，继续发挥 IDC 的价值，且不 100% 依赖于云。面对 IDC 或云故障场景，关键时刻要敢切换、能切换，且切换 RTO 要求小于 10 分钟。
  
  
  • 无数据一致性风险。云上云下的两个数据中心数据强一致，日常态和容灾切换过程中都要避免存在脏写等数据一致性风险。
  
  
  • 一站式管控。业务容灾涉及的技术栈框架和云产品，需要统一管控、统一运维、统一切换，操作收敛在一站式管控平台，方便故障场景快速白屏化操作，自动化执行。
  
  
  • 实施周期短，改造成本低。业务存在多个产品线，依赖关系复杂、调用链路长，且处于高速发展频繁迭代时期，期望容灾建设不会给业务研发团队带来改造负担。
  
  3 建设难点

  
  

  
  

  • 流量管理难度高
  
  
  • 若采用 DNS 将流量按权重解析到云上和云下，存在修改 DNS 解析生效时间长的问题（通常为十分钟或小时级，参见 DNS 解析生效时间 FAQ^[2]），不能满足容灾切换小于 10 分钟的要求。
  • 
    
  • 业务应用所依赖的 Redis 和 MySQL，IDC内采用开源自建而云上直接使用云产品，要实现开源自建+云产品的容灾切换能力难。
  • 
    
  • 容灾切换数据质量保障难
  
  
  • 容灾切换过程中，可能因数据同步延迟导致读到旧数据，以及切换规则推送到分布式应用节点时间不一致等原因可能造成云上云下数据库同时读写而出现脏写的问题，整个切换过程数据质量保障是个关键点，同时也是难点。
  • 
    
  • 无业务代码侵入难
  
  
  • 要实现 Redis、MySQL 容灾切换能力，通常需要业务应用配合改造，对业务代码侵入大。
  
  4 解决方案

  
  

  结合业务容灾需求和混合云 IDC+云形态的特点，采用应用双活架构能够较好的满足业务容灾诉求。
  

  应用双活架构

  
  架构简图：

  
  

  

  架构规范：
  
  • 选择离 IDC 物理距离<=200km 的云上 Region，网络延迟较低（约 5~7ms）。
  
  
  • 应用、中间件云上云下冗余对称部署，同时对外提供服务（应用双活）。
  
  
  • 数据库异地主备，异步复制备份。应用读写同一数据中心的数据库，避免考虑一致性问题。
  
  

  详细方案

  

  
  

  容灾能力
  
  • RPO：<=1min（依赖于 DTS 同步性能）
  
  
  • RTO：<=1min（依赖于 DTS 同步延迟，MSHA 组件实现秒级切换。整体 RTO<=1min）
  
  7 容灾能力验证

  
  

  基于 MSHA 完成应用双活架构建设后，还需验证业务容灾能力是否符合预期。接下来将制造真实的故障，来验证容灾恢复能力。
  
  

  7.1 演练准备

  
  

  1. 进入 MSHA 控制台，在左侧菜单栏选择监控大盘。页面顶部，下拉选择切换到实际使用的命名空间。

     
     

  2. 查看页面中的各项监控指标。

  
  说明：演练前，基于 MSHA 流量监控或其他监控产品，确定业务稳态的监控指标（如日常情况 RT<=200ms，错误率<1%），以便在故障发生时判断故障影响面以及在故障恢复后判断业务的实际恢复情况。

  

• 7.2 应用故障注入

  
  这里我们使用阿里云故障演练产品，对阿里云-北京的商品应用注入故障。
  

  1. 进入 Chaos 故障演练产品控制台^[9]，顶部选择切换到相应地域，左侧导航栏选择我的空间。

     
     

  2. 在我的空间选择配置好的演练（50% 概率网络丢包），然后单击执行演练。

  

• 故障注入成功后，打开电商首页或进行下单，有概率出现访问异常，符合预期。

  
  

• 7.3 切流恢复

  
  

  在北京单元的商品应用故障的情况下，可以通过 MSHA 切流功能，将云上入口流量切 0，快速恢复业务。

  
  

  预期

  
  

  100% 流量切换到杭州单元后，业务完全恢复，不受北京单元的故障影响。

  
  

• 切流操作

  
  

  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. 主备切换详情页，可以看到切换进度和切换结果，任务进度 100% 后，表示切换完成。
• 5. 商品、订单、购物车数据库都主备切换完成后。多次访问电商 Demo 首页或进行下单，发现均已正常，主备切换后业务功能完全恢复，符合预期。03

  总结

  Cloud Native

  
  在本篇文章中，我们介绍了 MSHA 多活容灾助力企业进行混合云应用双活容灾建设的实践案例，给出了容灾架构建设实践方法，同时利用 Chaos 故障演练产品注入真实故障，来验证故障场景业务容灾能力是否符合预期。