读多写少型业务场景多活实践

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群版 2核4GB 100GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介: 多活容灾MSHA(Multi-Site High Availability)是在阿⾥巴巴电商业务环境演进出的多活容灾架构解决⽅案。本文通过一个电商业务导购链路案例,介绍典型的读多写少型业务场景,如何基于多活容灾解决方案(AHAS-MSHA)帮助业务实现多活容灾架构。

多活容灾MSHA(Multi-Site High Availability)是在阿⾥巴巴电商业务环境演进出的多活容灾架构解决⽅案。本文通过一个电商业务导购链路案例,介绍典型的读多写少型业务场景,如何基于多活容灾解决方案(AHAS-MSHA)帮助业务实现多活容灾架构。

背景信息

本文示例应用包含以下模块:

  • frontend:入口Web应用,负责和用户交互。
  • cartservice:购物车应用。记录用户的购物车数据,使用自建的Redis。
  • productservice:商品应用。提供商品、库存服务,使用RDS MySQL。
  • checkoutservice:下单应用。将购物车中的商品生成购买订单,使用RDS MySQL。

技术栈:

  • SpringBoot。
  • RPC框架:SpringCloud,注册中心使用自建的Eureka。

体验地址:

  • 多活容灾控制台:
    1. 登录AHAS控制台
    2. 在控制台左侧导航栏单击多活容灾
    3. 在顶部菜单栏,命名空间选择官方示例命名空间
  • 电商业务页面:Demo

案例背景:一次故障的发生

例如本示例的电商业务,包括导购、购物车、交易等业务场景。但在电商业务初期,很多互联网企业都没有考虑容灾问题,只在单地域进行了部署,部署的电商应用架构1.0如下图所示,只在杭州单元部署了相关业务。

电商应用架构1.0

与许多企业一样,该电商业务首次开始考虑容灾建设,是源于一次商品应用的故障,导致导购页面长时间无法访问,电商业务瘫痪。虽然故障最终得以解决,但故障导致的客户流失和企业口碑影响,对快速发展的业务造成不小的打击,迫使企业开始考虑容灾能力的建设。

这次故障中受损的导购业务,是典型的读多写少型业务场景,包括以下链路:

  • 导购页面的展示,是读链路。
  • 电商后台发布、上架商品(从而在导购页面能够展示出来),是写链路。

导购业务,用户关注的是导购页中的商品信息,通常不关注商品的上架过程。因此读链路是核心,而写链路是可以被接受短暂的不可用。这个读多写少的业务特点,就非常适合采用异地多读架构。读链路异地多活而写链路保持单点(单地域写),这样建设成本低、改造内容少、投入产出比高。所以接下来,我们将导购业务读链路相关的应用、中间件、数据库进行异地部署和多活改造。

异地多读架构改造

基于MSHA多活容灾解决方案,可以快速的帮助业务进行异地多读容灾建设。

多活改造和MSHA接入包括以下方面:

  • 分区维度:电商业务适合使用UserID来作分流标识。只需将域名流量Http Header/Cookie带上UserID标识,MSHA接入层就可以根据标识进行流量的路由。
  • 改造范围:将导购链路相关的入口Web应用、商品应用以及商品MySQL数据库,在新地域进行冗余和对等的部署。
  • 管控配置:进入MSHA控制台进行各层多活资源的配置(接入层域名/URI/SLB等,数据层数据同步等)。

改造后的应用架构如下图所示。

导购链路.png

复现故障

改造完成容灾架构后,还需验证容灾能力是否符合预期。接下来将历史故障进行复现,通过制造真实的故障来验证容灾恢复能力。

  1. 演练准备。
    1. 登录AHAS控制台
    2. 在控制台左侧导航栏选择多活容灾
    3. 在左侧导航栏选择监控大盘,在顶部菜单栏,选择命名空间官方示例命名空间
    4. 异地双活区域,查看业务稳态监控指标。
      说明 基于MSHA流量监控或其他监控能力,确定业务稳态的监控指标,以便在故障发生时判断故障影响面以及在故障恢复后判断业务的实际恢复情况。

      演练预期如下:

      • 导购链路对购物车应用是弱依赖(导购页会展示用户放入购物车的商品数量),弱依赖故障不影响业务。
      • 导购链路对商品应用是强依赖,强依赖故障将导致业务不可用,因此故障的爆炸半径应该控制在单元内。
    5. 创建故障演练。
      创建杭州单元商品中心故障的演练,具体操作,请参见 创建演练
  2. 故障注入。
    1. 在多活容灾的监控大盘页面异地双活区域,查看故障演练前配置的路由规则。

      本示例中UserID为0~1575之间的用户会路由到杭州单元,UserID为1576~9999之间的用户会路由到北京单元。

      路由规则1.png

      示例的MSHA商城商品应用链路如下图所示,UserID为1000的用户路由到杭州单元。

      查看链路1.png
    2. 对杭州单元的商品应用注入故障。
      1. AHAS控制台的左侧导航栏选择故障演练 > 我的空间
      2. 我的空间单击演练准备中创建的演练,然后单击演练
      3. 开始执行演练对话框中单击确认故障注入.png

        若故障注入成功,UserID为1000的用户路由到的杭州单元会受到影响,导购页访问异常,符合预期。

        访问失败.png
      4. 可选:验证爆炸半径。
        验证爆炸半径是否控制在故障单元内:
        • 预期:UserID为2000的用户路由到北京单元,不受杭州单元故障的影响。
        • 结果:导购页访问正常,符合预期。

切流恢复

接下来将验证故障场景下的容灾恢复能力。在杭州单元发生故障的情况下,可以使用MSHA切流功能将受影响的用户流量切换到另外的单元,进行快速业务恢复(这里区别于传统的思路,不是去排查、处理和修复故障,而是立即使用切流进行恢复,将业务恢复和故障恢复解耦)。

容灾切换预期:将UserID为1000的用户切流到北京单元,切流后该用户将路由到北京单元,不受杭州单元故障的影响。

  1. 登录AHAS控制台
  2. 在控制台左侧导航栏中选择多活容灾
  3. 在左侧导航栏选择基础配置 > 命名空间,在顶部菜单栏选择官方示例命名空间
  4. 在多活容灾的左侧导航栏选择切流 > 异地双活切流
  5. 异地双活切流页面,单击切流
  6. 切流详情页面的规则调整区域,滑动北京单元的滑块,使得UserID 1000在北京单元的规则内。
  7. 单击生成预览,然后在生成区域单击执行预检查,在切流检查区域,单击确认
  8. 切流确认对话框中,单击确定
    切流任务页面的 当前状态显示 切流完成,表示切流已成功。 切流.png
  9. 刷新MSHA商城导购页。

    MSHA商城导购页可再次正常访问,符合预期。

    访问成功.png

    通过查看导购请求的实际调用链路,UserID为1000的用户已路由到北京单元,不受杭州单元故障的影响,符合预期。

    查看链路2.png

功能演示

故障注入和切流恢复的功能演示如下。

后续步骤

您还需要进行以下操作:

  • 终止注入故障,具体操作,请参见停止演练
  • 反馈演练结果,记录演练识别到的风险问题,具体操作,请参见反馈演练结果
  • 回切流量,将MSHA的路由规则恢复到演练前的状态,具体操作,请参见异地双活切流
  • 查看业务的稳态指标已恢复,具体操作,请参见本文复现故障

相关文档

相关文章
|
2月前
|
存储 运维 容灾
带你读《云上自动化运维宝典》——一文详解云上跨可用区容灾解决方案和异地多活能力建设最佳案例(3)
带你读《云上自动化运维宝典》——一文详解云上跨可用区容灾解决方案和异地多活能力建设最佳案例(3)
152 0
|
2月前
|
弹性计算 容灾 网络协议
一文详解云上跨可用区容灾解决方案和异地多活能力建设最佳案例
阿里云弹性计算团队十三位产品专家和技术专家共同分享云上运维深度实践,详细阐述如何利用CloudOps工具实现运维提效、弹性降本。
250 0
|
2月前
|
弹性计算 运维 容灾
带你读《云上自动化运维宝典》——一文详解云上跨可用区容灾解决方案和异地多活能力建设最佳案例(1)
带你读《云上自动化运维宝典》——一文详解云上跨可用区容灾解决方案和异地多活能力建设最佳案例(1)
221 1
|
2月前
|
弹性计算 运维 容灾
带你读《云上自动化运维宝典》——一文详解云上跨可用区容灾解决方案和异地多活能力建设最佳案例(2)
带你读《云上自动化运维宝典》——一文详解云上跨可用区容灾解决方案和异地多活能力建设最佳案例(2)
150 1
|
负载均衡 容灾 网络协议
《云上容灾交付服务白皮书》——2.容灾技术架构——21容灾技术架构简介(上)
《云上容灾交付服务白皮书》——2.容灾技术架构——21容灾技术架构简介(上)
464 0
|
7月前
|
关系型数据库 Serverless 分布式数据库
PolarDB Serverless能力测评:秒级弹升、无感伸缩与强一致性,助您实现高效云数据库管理!
云原生数据库 PolarDB MySQL 版是阿里云自研产品,100%兼容 MySQL。PolarDB产品具有多主多写、多活容灾、HTAP 等特性,交易性能最高可达开源数据库的6倍,分析性能最高可达开源数据库的400倍,TCO 低于自建数据库50%。【评测用!】
70479 15
|
2月前
|
存储 运维 负载均衡
探索容灾架构演进之路 - 从单点到异地多活
容灾架构的选择在于平衡可用性需求和成本之间的关系。并不存在一种完美的架构,而是应该根据业务发展的阶段逐步演进容灾架构,避免陷入过度设计和资源浪费的困境
203 0
|
容灾
《云上容灾交付服务白皮书》——2.容灾技术架构——2.2 容灾技术架构选型
《云上容灾交付服务白皮书》——2.容灾技术架构——2.2 容灾技术架构选型
134 0
|
边缘计算 容灾 Cloud Native
《云上容灾交付服务白皮书》——2.容灾技术架构——21容灾技术架构简介(下)
《云上容灾交付服务白皮书》——2.容灾技术架构——21容灾技术架构简介(下)
469 0
|
容灾 数据处理 UED
《云上容灾交付服务白皮书》——2.容灾技术架构——1.1 基础术语说明
《云上容灾交付服务白皮书》——2.容灾技术架构——1.1 基础术语说明
249 0