流水单据型业务场景多活实践

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介: 多活容灾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。

Demo体验地址:

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

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

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

电商应用架构1.0

读多写少型业务场景多活实践中,已经将导购链路进行了异地多读改造,而该业务后续在一次大促期间,遭遇了一次订单应用大面积故障,导致大促期间下单业务长时间无法使用,于是下单业务的容灾建设也提上了议程。下单业务是典型的流水单据型业务场景,相比导购,是更为复杂的读写业务,结合业务场景和业务容灾诉求,异地多活是适合此业务的容灾建设方案。

异地多活容灾架构改造

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

说明 下单链路强依赖购物车应用,完整的多活容灾建设,后续还应将购物车应用也改造为异地多活。

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

  • 改造范围:下单应用和订单数据库进行两地域部署。
  • MSHA接入:将下单链路的应用安装上Agent,从而无侵入的实现SpringCloud RPC跨单元路由功能和数据防脏写功能。
  • 管控配置:进入MSHA控制台进行各层多活资源的配置(接入层域名、URI、SLB、数据层数据同步等)。

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

异地多活容灾架构.png

复现故障

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

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

      演练预期如下:

      • 下单链路对订单应用是强依赖,强依赖故障会影响业务不可用。
      • 故障爆炸半径控制在单元内。
    5. 创建故障演练。
      创建北京单元下单应用故障的演练,具体操作,请参见 创建演练
  2. 故障注入。
    1. 在多活容灾的监控大盘页面异地双活区域,查看故障演练前配置的路由规则。

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

      路由规则2.png

      示例的MSHA商城下单应用链路如下图所示,当UserID为7000的用户路由到北京单元。

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

        若故障注入成功,UserID为7000的用户路由到的北京单元会受到影响,下单页访问异常,符合预期。

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

切流恢复

验证故障场景下的容灾恢复能力。在北京单元发生故障的情况下,可以使用MSHA切流功能将受影响的用户流量切换到另外的单元,进行快速业务恢复。

说明 这里区别于传统的解决思路,不是去排查、处理和修复故障,而是立即使用切流进行恢复,将业务恢复和故障恢复解耦。

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

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

    MSHA商城下单正常,符合预期。

    下单成功.png

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

    查看链路4.png

功能演示

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

后续步骤

您还需要进行以下操作:

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

相关文档

相关文章
|
5月前
|
监控
阿里商旅账单系统架构设计实践问题之对账模型包括内容问题如何解决
阿里商旅账单系统架构设计实践问题之对账模型包括内容问题如何解决
|
4月前
|
领域建模
重构支付宝商家账单问题之离线任务的稳定性问题该如何应对
重构支付宝商家账单问题之离线任务的稳定性问题该如何应对
|
5月前
|
搜索推荐 Java
阿里商旅账单系统架构设计实践问题之需要账单数据表达式引擎问题如何解决
阿里商旅账单系统架构设计实践问题之需要账单数据表达式引擎问题如何解决
|
数据采集 存储 数据库
2、电商数仓(业务数据采集平台)电商业务流程、电商常识、电商系统表结构、业务数据模拟、业务数据采集模块(一)
2、电商数仓(业务数据采集平台)电商业务流程、电商常识、电商系统表结构、业务数据模拟、业务数据采集模块(一)
|
NoSQL 算法 Java
千万级订单生成的痛点与架构
千万级订单生成的痛点与架构
191 0
|
存储 监控 供应链
聊聊「订单」业务的设计与实现
订单业务一直都是系统研发中的核心模块,订单的产生过程,与系统中的很多模块都会高度关联,比如账户体系、支付中心、运营管理等,即便单看订单本身,也足够的复杂;
11721 3
聊聊「订单」业务的设计与实现
|
数据采集 消息中间件 数据可视化
2、电商数仓(业务数据采集平台)电商业务流程、电商常识、电商系统表结构、业务数据模拟、业务数据采集模块(二)
2、电商数仓(业务数据采集平台)电商业务流程、电商常识、电商系统表结构、业务数据模拟、业务数据采集模块(二)
|
存储 消息中间件 JavaScript
支付设计白皮书:支付系统的对账系统设计
支付设计白皮书:支付系统的对账系统设计
|
存储 SQL 关系型数据库
万级TPS亿级流水-中台账户系统架构设计
我们需要给所有前台业务提供统一的账户系统,用来支撑所有前台产品线的用户资产管理,统一提供支持大并发万级TPS、亿级流水、数据强一致、风控安全、日切对账、财务核算、审计等能力,在万级TPS下保证绝对的数据准确性和数据溯源能力。 >注:资金类系统只有合格和不合格,哪怕数据出现只有0.01分的差错也是不合格的,局部数据不准也就意味着全局数据都不可信。
1608 0
|
存储 NoSQL 调度
双11实时物流订单最佳实践
随着双11的开启,物流业也迎来了年度大考。2021年双11期间,递四方作为物流仓储服务方,布局仓库和分拣点超40+个,50w+平米作业场地,单日订单峰值达千万级别,海量购物订单由递四方配送到家,消费者由尾款人秒变收货人。
双11实时物流订单最佳实践
下一篇
DataWorks