MSHA x Chaos 容灾高可用实践

简介：MSHA x Chaos 容灾高可用实践

1. 前言

由于外部环境的复杂以及硬件的不可靠，互联网服务的高可用面临着巨大的挑战，由于断网、断电等事故导致的各大互联网公司服务不可用的案例也不在少数。业务不可用，小到带来经济损失影响企业口碑，大到微信、支付宝这些国民级应用，影响国计民生。面对难以避免的天灾人祸，容灾架构的建设就成为了数字化企业的迫切诉求。
2020 年 12 月份，阿里云应用高可用产品 AHAS（Application High Availability Service）发布了新的功能模块 AHAS-MSHA，它是在阿⾥巴巴电商业务环境演进出来的多活容灾架构解决⽅案。本篇文章我们首先介绍容灾领域的几个重要概念，然后将结合一个的电商微服务案例，分享一下如何基于 AHAS 的异地多活能力（AHAS-MSHA）和混沌工程能力（AHAS-Chaos）帮助业务实现容灾架构的高可用实践。

2. 容灾与评价指标

2.1 什么是容灾

容灾（Disaster Tolerance）是指在相隔较远的异地，建立两套或多套功能相同的系统，系统之间可以相互进行健康状态监视和功能切换，当一处系统因意外（如火灾、洪水、地震、人为蓄意破坏等）停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。

2.2 容灾能力如何评估

容灾系统主要为了在灾难发生时业务不发生中断，那么容灾能力如何评估和量化呢？这里需要介绍一下业界通常采用的容灾能力评价指标：

• RPO（Recovery Point Objective）

即数据恢复点目标，以时间为单位，即在灾难发生时，系统和数据必须恢复的时间点要求。RPO 标志系统能够容忍的最大数据丢失量，系统容忍丢失的数据量越小，RPO 的值越小。

• RTO（Recovery Time Objective）

即恢复时间目标，以时间为单位，即在灾难发生后，信息系统或业务功能从停止到必须恢复的时间要求。RTO 标志系统能够容忍的服务停止的最长时间，系统服务的紧迫性要求越高，RTO 的值越小。

3. AHAS-MSHA

3.1 介绍

MSHA（Multi-Site High Availability）是一个多活容灾架构解决⽅案（解决方案=技术产品+咨询服务+生态伙伴），可以将业务恢复和故障恢复解耦，支持故障场景下业务的快速恢复，助⼒企业的容灾稳定性建设。

1）产品架构
MSHA 采用异地多活的容灾架构，核心思想是 “隔离的冗余”，我们将各个冗余的逻辑数据中心称为单元，MSHA 做到了业务流量在单元内封闭，单元之间隔离，把故障爆炸半径控制在一个单元内，不仅能解决容灾问题，提升业务连续性，并且能实现容量的扩展。

2）主流容灾架构对比

3.2 功能特性

1）故障快速恢复
秉承先恢复，再定位的原则，MSHA 提供了容灾切流能力，在数据保护的前提下让业务恢复时间和故障恢复时间解耦合，保障业务连续性。

2）容量异地扩展
业务⾼速发展，受限于单地有限资源，也存在数据库瓶颈等问题。使用 MSHA 可以在其它地域、机房快速扩建业务单元，实现快速水平扩容的目的。

3）流量分配与纠错
MSHA 提供了从接入层到应用层的层层流量纠错和校验，将不符合流量路由规则的调用重新转发，将故障爆炸半径可控制在一个单元内。

4）数据防脏写
多单元写数据可能造成脏写覆盖的问题，MSHA 提供流量打入错误单元时的禁写保护，以及切流数据同步延时期间的禁写/禁更新保护。

3.3 应用场景

MSHA 可适用于以下典型业务场景的多活容灾架构建设：
1）读多写少型业务

• 业务场景：典型的业务场景就是资讯、导购类服务（如商品浏览、新闻资讯）。
• 数据特点：读多写少型业务，核心是读业务，能够接受写业务的暂时不可用。

2）流水单据型业务

• 业务场景：典型的业务场景就是电商交易、账单流水类服务（如订单、通话记录等）。
• 数据特点：数据可以按一定的维度进行分片且能接受数据的最终一致。

4. 业务容灾实践

下面我们通过一个电商微服务案例，来介绍不同场景的容灾架构建设案例。

4.1 电商业务背景

1）业务应用

• frontend，入口 WEB 应用，负责和用户交互
• cartservice，购物车应用。记录用户的购物车数据，使用自建的 Redis
• productservice，商品应用。提供商品、库存服务，使用 RDS MySQL
• checkoutservice，下单应用。将购物车中的商品生成购买订单，使用 RDS MySQL

2）技术栈

• SpringBoot
• RPC 框架：SpringCloud，注册中心使用自建的 Eureka

3）电商应用架构 1.0
电商业务初期，跟很多互联网企业一样，没有考虑容灾问题，只在单地域进行了部署。

4.2 案例一：读多写少型业务容灾案例

4.2.1 一次故障的发生

电商业务初期发展迅速，小而美的单地域部署方式也一直没有变化，直到一次商品应用故障的发生，导致电商业务瘫痪，页面长时间无法访问。故障最终得以解决，但故障导致的客户流失和企业口碑影响，对快速发展的业务造成不小的打击，迫使我们开始考虑高可用能力的建设。
电商业务主要分为导购、购物车、交易等业务场景，首当其冲的就是导购。它是典型的读多写少型业务场景，核心是导购页面的展示（读链路），通常可以接受发布、上架商品服务的暂时不可用（写链路）。结合自身容灾诉求，我们先定下一个改进的小目标--“异地多读”。

4.2.2 异地多读容灾架构改造

基于 MSHA 将导购业务改造为“异地多读”。
多活改造 & MSHA 接入：

• 分区维度：使用 userId 来作分流标识。
• 改造范围：将导购链路相关的入口 WEB 应用 、 商品应用 进行两地域部署。
• 管控配置：进入 MSHA 控制台进行各层多活资源的配置。

4.2.3 故障复现

容灾架构改造完成后，并没有结束，还需验证容灾能力是否符合预期。接下来我们将历史故障进行复现，通过制造真实的故障来验证容灾恢复能力。
1.演练准备
业务监控指标：基于 MSHA 流量监控或其他监控能力，确定业务稳态监控指标，以便在故障发生时判断故障影响面以及在故障恢复后判断业务的实际恢复情况。

演练预期：
导购链路对购物车应用是弱依赖（导购页会展示用户放入购物车的商品数量），弱依赖故障不影响业务。
导购链路对商品应用是强依赖，强依赖故障将导致业务不可用，故障的爆炸半径应该控制在单元内。
2.故障演练
利用AHAS-Chaos 故障演练功能，能够方便的进行多种故障场景的演练。
a）第一阶段 弱依赖故障演练

• 故障注入：对购物车应用进行故障注入
• 预期：导购业务不受影响
• 结果：导购页能正常打开，符合预期

b）第二阶段：强依赖故障演练
演练前配置的路由规则如下（userId%10000 后根据如下路由范围规则进行匹配）：

• 故障注入：对北京单元的商品应用进行故障注入
• 预期：userId=6000 的用户路由到北京单元，会受故障的影响
• 结果：导购页访问异常，符合预期

• 爆炸半径验证：验证保障半径是否控制在故障单元内
• 预期：userId=50 的用户路由到杭州单元，不受北京单元故障的影响
• 结果：导购页访问正常，符合预期

4.2.4 切流恢复

故障场景下，使用 MSHA 切流功能，验证容灾恢复能力。

• 容灾切换验证：将 userId=6000 切流到杭州单元
• 预期：切流后该用户将路由到杭州单元，不受北京单元故障的影响。
• 结果：导购页访问正常（导购请求的实际调用链参见下面动图），容灾恢复能力符合预期。

后续：故障撤销
故障注入终止
演练结果反馈，记录演练识别到的风险问题
流量回切
查看稳态业务指标是否恢复

4.3 案例二：流水单据型业务容灾案例

4.3.1 新的故障

经过上述的改造，导购业务已经具备抵御地域级故障的能力。而订单应用大面积故障，成为了压死订单业务的最后一根稻草。于是，下单业务的高可用架构建设，也提上了议程。
下单是典型的流水单据型业务场景，相比导购，是更为复杂的读写结合业务，结合业务场景和业务容灾诉求，我们选取了适合业务的容灾建设方案--“异地多活”。

4.3.2 异地多活容灾架构改造

基于 MSHA 将订单业务改造为“异地多活”。
注：下单链路强依赖购物车应用，完整的多活容灾建设，后续还应将购物车应用也改造为“异地多活”。
多活改造&MSHA接入：

• 改造范围：下单应用和订单数据库进行两地域部署。
• MSHA 接入：将下单链路的应用安装上 Agent，从而无侵入的实现 SpringCloud RPC 跨单元路由功能和数据防脏写功能。
• 管控配置：

4.3.3 故障复现

容灾架构改造完成后，接下来我们将历史故障进行复现，通过制造真实的故障来验证容灾恢复能力
1.演练准备

• 业务监控指标：基于 MSHA 流量监控或其他监控能力，确定业务稳态监控指标。
• 演练预期：下单链路对订单应用是强依赖，强依赖故障影响业务不可用，且故障爆炸半径控制在单元内。

2.故障演练

演练前配置的路由规则如下（userId%10000 后根据如下路由范围规则进行匹配）：

• 故障注入：对北京单元的订单应用进行故障注入
• 预期：userId=6000 的用户路由到北京单元，会受到故障影响
• 结果：下单异常，符合预期

• 爆炸半径验证：验证保障半径是否控制在故障单元内
• 预期：userId=50的用户路由到杭州单元，不受北京单元故障的影响
• 结果：下单正常，符合预期

4.3.4 切流恢复

使用 MSHA 切流功能，验证故障场景下的容灾切换能力。

• 容灾切换验证：将 userId=6000 切流到杭州单元
• 预期：切流后该用户将路由到杭州单元，不受北京单元故障的影响
• 结果：下单正常（下单请求的实际调用链参见下面动图），容灾恢复能力符合预期。

5. 总结

在本篇文章中，我们介绍了 AHAS 为业务容灾提供的一大利器：MSHA 多活容灾解决方案，并结合一个电商业务，介绍了读多写少型和流水单据型2个典型业务场景下的容灾建设案例，给出容灾架构建设实践方法，同时结合 AHAS-Chaos 故障演练功能模拟一次真实可能发生的故障，验证容灾能力是否符合预期。
最后想跟大家说的是，容灾建设是一个系统工程，不能一蹴而就也不是一锤子买卖，需要根据业务场景、容灾诉求、技术栈、容灾预算等综合来评估和制定合适的容灾架构建设方案，欢迎大家针对自身的容灾诉求和场景进行咨询和交流。

我们是阿里云智能全球技术服务-SRE团队，我们致力成为一个以技术为基础、面向服务、保障业务系统高可用的工程师团队；提供专业、体系化的SRE服务，帮助广大客户更好地使用云、基于云构建更加稳定可靠的业务系统，提升业务稳定性。我们期望能够分享更多帮助企业客户上云、用好云，让客户云上业务运行更加稳定可靠的技术。

原文链接：https://developer.aliyun.com/article/781484?

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。