多活容灾MSHA(Multi-Site High Availability)是在阿⾥巴巴电商业务环境演进出的多活容灾架构解决⽅案。本文通过一个电商业务导购链路案例,介绍典型的读多写少型业务场景,如何基于多活容灾解决方案(AHAS-MSHA)帮助业务实现多活容灾架构。
背景信息
本文示例应用包含以下模块:
frontend:入口Web应用,负责和用户交互。
cartservice:购物车应用。记录用户的购物车数据,使用自建的Redis。
productservice:商品应用。提供商品、库存服务,使用RDS MySQL。
checkoutservice:下单应用。将购物车中的商品生成购买订单,使用RDS MySQL。
技术栈:
SpringBoot。
RPC框架:SpringCloud,注册中心使用自建的Eureka。
体验地址:
多活容灾控制台:
登录AHAS控制台。
在控制台左侧导航栏单击多活容灾。
在顶部菜单栏,命名空间选择官方示例命名空间。
案例背景:一次故障的发生
例如本示例的电商业务,包括导购、购物车、交易等业务场景。但在电商业务初期,很多互联网企业都没有考虑容灾问题,只在单地域进行了部署,部署的电商应用架构1.0如下图所示,只在杭州单元部署了相关业务。
与许多企业一样,该电商业务首次开始考虑容灾建设,是源于一次商品应用的故障,导致导购页面长时间无法访问,电商业务瘫痪。虽然故障最终得以解决,但故障导致的客户流失和企业口碑影响,对快速发展的业务造成不小的打击,迫使企业开始考虑容灾能力的建设。
这次故障中受损的导购业务,是典型的读多写少型业务场景,包括以下链路:
导购页面的展示,是读链路。
电商后台发布、上架商品(从而在导购页面能够展示出来),是写链路。
导购业务,用户关注的是导购页中的商品信息,通常不关注商品的上架过程。因此读链路是核心,而写链路是可以被接受短暂的不可用。这个读多写少的业务特点,就非常适合采用异地多读架构。读链路异地多活而写链路保持单点(单地域写),这样建设成本低、改造内容少、投入产出比高。所以接下来,我们将导购业务读链路相关的应用、中间件、数据库进行异地部署和多活改造。
异地多读架构改造
基于MSHA多活容灾解决方案,可以快速的帮助业务进行异地多读容灾建设。
多活改造和MSHA接入包括以下方面:
分区维度:电商业务适合使用UserID来作分流标识。只需将域名流量Http Header/Cookie带上UserID标识,MSHA接入层就可以根据标识进行流量的路由。
改造范围:将导购链路相关的入口Web应用、商品应用以及商品MySQL数据库,在新地域进行冗余和对等的部署。
管控配置:进入MSHA控制台进行各层多活资源的配置(接入层域名/URI/SLB等,数据层数据同步等)。
改造后的应用架构如下图所示。
复现故障
改造完成容灾架构后,还需验证容灾能力是否符合预期。接下来将历史故障进行复现,通过制造真实的故障来验证容灾恢复能力。
演练准备。
故障注入。
在多活容灾的监控大盘页面异地双活区域,查看故障演练前配置的路由规则。
本示例中UserID为0~1575之间的用户会路由到杭州单元,UserID为1576~9999之间的用户会路由到北京单元。
示例的MSHA商城商品应用链路如下图所示,UserID为1000的用户路由到杭州单元。
对杭州单元的商品应用注入故障。
在AHAS控制台的左侧导航栏选择 。
在我的空间单击演练准备中创建的演练,然后单击演练。
在开始执行演练对话框中单击确认。
若故障注入成功,UserID为1000的用户路由到的杭州单元会受到影响,导购页访问异常,符合预期。
可选:验证爆炸半径。
验证爆炸半径是否控制在故障单元内:
预期:UserID为2000的用户路由到北京单元,不受杭州单元故障的影响。
结果:导购页访问正常,符合预期。
切流恢复
接下来将验证故障场景下的容灾恢复能力。在杭州单元发生故障的情况下,可以使用MSHA切流功能将受影响的用户流量切换到另外的单元,进行快速业务恢复(这里区别于传统的思路,不是去排查、处理和修复故障,而是立即使用切流进行恢复,将业务恢复和故障恢复解耦)。
容灾切换预期:将UserID为1000的用户切流到北京单元,切流后该用户将路由到北京单元,不受杭州单元故障的影响。
登录AHAS控制台。
- 在控制台左侧导航栏中单击多活容灾。
在左侧导航栏选择 ,在顶部菜单栏选择官方示例命名空间。
在多活容灾的左侧导航栏选择 。
在异地双活切流页面,单击切流。
在切流详情页面的规则调整区域,滑动北京单元的滑块,使得UserID 1000在北京单元的规则内。
单击生成预览,然后在生成区域单击执行预检查,在切流检查区域,单击确认。
在切流确认对话框中,单击确定。
在切流任务页面的当前状态显示切流完成,表示切流已成功。
刷新MSHA商城导购页。
MSHA商城导购页可再次正常访问,符合预期。
通过查看导购请求的实际调用链路,UserID为1000的用户已路由到北京单元,不受杭州单元故障的影响,符合预期。
功能演示
故障注入和切流恢复的功能演示如下。
后续步骤
您还需要进行以下操作: