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