多活容灾MSHA（Multi-Site High Availability）是在阿⾥巴巴电商业务环境演进出的多活容灾架构解决⽅案。本文通过一个电商业务下单链路案例，介绍典型的流水单据型业务场景，如何基于多活容灾解决方案（AHAS-MSHA）帮助业务实现多活容灾架构。
背景信息
本文示例应用包含以下模块：
frontend：入口Web应用。负责和用户交互。
cartservice：购物车应用。记录用户的购物车数据，使用自建的Redis。
productservice：商品应用。提供商品、库存服务，使用RDS MySQL。
checkoutservice：下单应用。将购物车中的商品生成购买订单，使用RDS MySQL。
技术栈：
SpringBoot。
RPC框架：SpringCloud，注册中心使用自建的Eureka。
Demo体验地址：
多活容灾控制台：
登录AHAS控制台。
在控制台左侧导航栏选择多活容灾。
在顶部菜单栏，命名空间选择官方示例命名空间。
案例背景：一次故障的发生
例如本示例的电商业务，包括导购、购物车、交易等业务场景。但在电商业务初期，很多互联网企业都没有考虑容灾问题，只在单地域进行了部署，部署的电商应用架构1.0如下图所示，只在杭州单元部署了相关业务。
在读多写少型业务场景多活实践中，已经将导购链路进行了异地多读改造，而该业务后续在一次大促期间，遭遇了一次订单应用大面积故障，导致大促期间下单业务长时间无法使用，于是下单业务的容灾建设也提上了议程。下单业务是典型的流水单据型业务场景，相比导购，是更为复杂的读写业务，结合业务场景和业务容灾诉求，异地多活是适合此业务的容灾建设方案。
异地多活容灾架构改造
基于MSHA多活容灾解决方案，可以快速的帮助业务进行异地多活容灾建设。
下单链路强依赖购物车应用，完整的多活容灾建设，后续还应将购物车应用也改造为异地多活。
多活改造和MSHA接入包括以下方面：
改造范围：下单应用和订单数据库进行两地域部署。
MSHA接入：将下单链路的应用安装上Agent，从而无侵入的实现SpringCloud RPC跨单元路由功能和数据防脏写功能。
管控配置：进入MSHA控制台进行各层多活资源的配置（接入层域名、URI、SLB、数据层数据同步等）。
改造后的应用架构如下图所示。
复现故障
改造完成容灾架构后，还需验证容灾能力是否符合预期，接下来将历史故障进行复现，通过制造真实的故障来验证容灾恢复能力。
演练准备。
故障注入。
在多活容灾的监控大盘页面异地双活区域，查看故障演练前配置的路由规则。
本示例中UserID为0~6652之间的用户会路由到杭州中心单元，UserID为6653~9999之间的用户会路由到北京单元。
示例的MSHA商城下单应用链路如下图所示，当UserID为7000的用户路由到北京单元。
对北京单元的下单应用注入故障。
在AHAS控制台的左侧导航栏选择。
在我的空间单击演练准备中创建的演练，然后单击演练。
在开始执行演练对话框中单击确认。
若故障注入成功，UserID为7000的用户路由到的北京单元会受到影响，下单页访问异常，符合预期。
可选：验证爆炸半径。
验证爆炸半径是否控制在故障单元内：
预期：UserID为2000的用户路由到杭州单元，不受北京单元故障的影响。
结果：下单正常，符合预期。
切流恢复
验证故障场景下的容灾恢复能力。在北京单元发生故障的情况下，可以使用MSHA切流功能将受影响的用户流量切换到另外的单元，进行快速业务恢复。
这里区别于传统的解决思路，不是去排查、处理和修复故障，而是立即使用切流进行恢复，将业务恢复和故障恢复解耦。
容灾切换预期：将UserID为7000的用户切流到杭州单元，切流后该用户将路由到杭州单元，不受北京单元故障的影响。
登录AHAS控制台。
- 在控制台左侧导航栏中单击多活容灾。
在左侧导航栏选择，在顶部菜单栏选择官方示例命名空间。
在多活容灾的左侧导航栏选择。
在异地双活切流页面，单击切流。
在切流详情页面的规则调整区域，滑动杭州中心单元的滑块，使得UserID 7000在杭州中心单元的规则内。
单击生成预览，然后在生成区域单击执行预检查，在切流检查区域，单击确认。
在切流确认对话框中，单击确定。
在切流任务页面的当前状态显示切流完成，表示切流已成功。
重新在MSHA商城下订单。
MSHA商城下单正常，符合预期。
通过查看下单请求的实际调用链路，UserID为7000的用户已路由到杭州单元，不受北京单元故障的影响，符合预期。
功能演示
故障注入和切流恢复的功能演示如下。
后续步骤
您还需要进行以下操作：