多活容灾MSHA(Multi-Site High Availability)是在阿⾥巴巴电商业务环境演进出的多活容灾架构解决⽅案。本文通过一个电商业务下单链路案例,介绍典型的流水单据型业务场景,如何基于多活容灾解决方案(AHAS-MSHA)帮助业务实现多活容灾架构。
背景信息
本文示例应用包含以下模块:
- frontend:入口Web应用。负责和用户交互。
- cartservice:购物车应用。记录用户的购物车数据,使用自建的Redis。
- productservice:商品应用。提供商品、库存服务,使用RDS MySQL。
- checkoutservice:下单应用。将购物车中的商品生成购买订单,使用RDS MySQL。
技术栈:
- SpringBoot。
- RPC框架:SpringCloud,注册中心使用自建的Eureka。
Demo体验地址:
案例背景:一次故障的发生
例如本示例的电商业务,包括导购、购物车、交易等业务场景。但在电商业务初期,很多互联网企业都没有考虑容灾问题,只在单地域进行了部署,部署的电商应用架构1.0如下图所示,只在杭州单元部署了相关业务。
在读多写少型业务场景多活实践中,已经将导购链路进行了异地多读改造,而该业务后续在一次大促期间,遭遇了一次订单应用大面积故障,导致大促期间下单业务长时间无法使用,于是下单业务的容灾建设也提上了议程。下单业务是典型的流水单据型业务场景,相比导购,是更为复杂的读写业务,结合业务场景和业务容灾诉求,异地多活是适合此业务的容灾建设方案。
异地多活容灾架构改造
基于MSHA多活容灾解决方案,可以快速的帮助业务进行异地多活容灾建设。
说明 下单链路强依赖购物车应用,完整的多活容灾建设,后续还应将购物车应用也改造为异地多活。
多活改造和MSHA接入包括以下方面:
- 改造范围:下单应用和订单数据库进行两地域部署。
- MSHA接入:将下单链路的应用安装上Agent,从而无侵入的实现SpringCloud RPC跨单元路由功能和数据防脏写功能。
- 管控配置:进入MSHA控制台进行各层多活资源的配置(接入层域名、URI、SLB、数据层数据同步等)。
改造后的应用架构如下图所示。
复现故障
改造完成容灾架构后,还需验证容灾能力是否符合预期,接下来将历史故障进行复现,通过制造真实的故障来验证容灾恢复能力。
- 演练准备。
- 故障注入。
切流恢复
验证故障场景下的容灾恢复能力。在北京单元发生故障的情况下,可以使用MSHA切流功能将受影响的用户流量切换到另外的单元,进行快速业务恢复。
说明 这里区别于传统的解决思路,不是去排查、处理和修复故障,而是立即使用切流进行恢复,将业务恢复和故障恢复解耦。
容灾切换预期:将UserID为7000的用户切流到杭州单元,切流后该用户将路由到杭州单元,不受北京单元故障的影响。
功能演示
故障注入和切流恢复的功能演示如下。
后续步骤
您还需要进行以下操作:
- 终止注入故障,具体操作,请参见停止演练。
- 反馈演练结果,记录演练识别到的风险问题,具体操作,请参见反馈演练结果。
- 回切流量,将MSHA的路由规则恢复到演练前的状态,具体操作,请参见异地双活切流。
- 查看稳态业务指标已恢复,具体操作,请参见本文复现故障。