作者 | 远跖、瀚阑
起源 |阿里巴巴云原生公众号
前言
因为外部环境的简单以及硬件的不牢靠，互联网服务的高可用面临着微小的挑战，因为断网、断电等事变导致的各大互联网公司服务不可用的案例也不在少数。业务不可用，小到带来经济损失影响企业口碑，大到微信、支付宝这些国民级利用，影响国计民生。面对难以避免的天下大乱，容灾架构的建设就成为了数字化企业的迫切诉求。
2020 年 12 月份，阿里云利用高可用产品 AHAS（Application High Availability Service）公布了新的功能模块 AHAS-MSHA，它是在阿⾥巴巴电商业务环境演进进去的多活容灾架构解决⽅案。本篇文章咱们首先介绍容灾畛域的几个重要概念，而后将联合一个的电商微服务案例，分享一下如何基于 AHAS 的异地多活能力（AHAS-MSHA）和混沌工程能力（AHAS-Chaos）帮忙业务实现容灾架构的高可用实际。
容灾与评估指标
1. 什么是容灾？
容灾（Disaster Tolerance）是指在相隔较远的异地，建设两套或多套性能雷同的零碎，零碎之间能够互相进行衰弱状态监督和性能切换，当一处零碎因意外（如火灾、洪水、地震、人为蓄意毁坏等）进行工作时，整个利用零碎能够切换到另一处，使得该零碎性能能够持续失常工作。
2. 容灾能力如何评估？
容灾零碎次要为了在劫难产生时业务不产生中断，那么容灾能力如何评估和量化呢？这里须要介绍一下业界通常采纳的容灾能力评估指标：
- RPO（Recovery Point Objective）
即数据恢复点指标，以工夫为单位，即在劫难产生时，零碎和数据必须复原的工夫点要求。RPO 标记零碎可能容忍的最大数据失落量，零碎容忍失落的数据量越小，RPO 的值越小。
- RTO（Recovery Time Objective）
即复原工夫指标，以工夫为单位，即在劫难产生后，信息系统或业务性能从进行到必须复原的工夫要求。RTO 标记零碎可能容忍的服务进行的最长工夫，零碎服务的紧迫性要求越高，RTO 的值越小。
AHAS-MSHA
1. 介绍
MSHA（Multi-Site High Availability）是一个多活容灾架构解决⽅案（解决方案 = 技术产品 + 咨询服务 + 生态搭档），能够将业务复原和故障复原解耦，反对故障场景下业务的疾速复原，助⼒企业的容灾稳定性建设。
1）产品架构
MSHA 采纳 异地多活 的容灾架构，核心思想是“隔离的冗余”，咱们将各个冗余的逻辑数据中心称为 单元 ，MSHA 做到了业务流量在单元内关闭，单元之间隔离，把故障 爆炸半径 管制在 一个单元 内，不仅能解决 容灾 问题，晋升业务连续性，并且能实现 容量 的扩大。
2）支流容灾架构比照
2. 性能个性
- 故障疾速复原
秉承 先复原，再定位 的准则，MSHA 提供了容灾切流能力，在数据保护的前提下让 业务复原工夫 和故障复原工夫 解耦合，保障业务连续性。
- 容量异地扩大
业务⾼速倒退，受限于单地无限资源，也存在数据库瓶颈等问题。应用 MSHA 能够在其它地区、机房疾速扩建业务单元，实现疾速程度扩容的目标。
- 流量调配与纠错
MSHA 提供了从接入层到应用层的层层流量纠错和校验，将不合乎流量路由规定的调用从新转发，将故障爆炸半径可管制在一个单元内。
- 数据防脏写
多单元写数据可能造成脏写笼罩的问题，MSHA 提供流量打入谬误单元时的禁写爱护，以及切流数据同步延时期间的禁写 / 禁更新爱护。
3. 利用场景
MSHA 可实用于以下典型业务场景的多活容灾架构建设：
-
读多写少型业务
- 业务场景：典型的业务场景就是资讯、导购类服务（如商品浏览、新闻资讯）。
- 数据特点：读多写少型业务，外围是读业务，可能承受写业务的临时不可用。
-
流水单据型业务
- 业务场景：典型的业务场景就是电商交易、账单流水类服务（如订单、通话记录等）。
- 数据特点：数据能够按肯定的维度进行分片且能承受数据的最终统一。
业务容灾实际
上面咱们通过一个电商微服务案例，来介绍不同场景的容灾架构建设案例。
1. 电商业务背景
1）业务利用
- frontend，入口 WEB 利用，负责和用户交互
- cartservice，购物车利用。记录用户的购物车数据，应用自建的 Redis
- productservice，商品利用。提供商品、库存服务，应用 RDS MySQL
- checkoutservice，下单利用。将购物车中的商品生成购买订单，应用 RDS MySQL
2）技术栈
- SpringBoot
- RPC 框架：SpringCloud，注册核心应用自建的 Eureka
3）电商利用架构 1.0
电商业务初期，跟很多互联网企业一样，没有思考容灾问题，只在单地区进行了部署。
2. 案例一：读多写少型业务容灾案例
1）一次故障的产生
电商业务初期倒退迅速，小而美的单地区部署形式也始终没有变动，直到一次商品利用 故障 的产生，导致电商业务瘫痪，页面长时间无法访问。故障最终得以解决，但故障导致的客户散失和企业口碑影响，对疾速倒退的业务造成不小的打击，迫使咱们开始思考高可用能力的建设。
电商业务次要分为导购、购物车、交易等业务场景，首当其冲的就是导购。它是典型的读多写少型业务场景，外围是导购页面的展现（读链路），通常能够承受公布、上架商品服务的临时不可用（写链路）。联合本身容灾诉求，咱们先定下一个改良的小指标 –“异地多读”。
2）异地多读容灾架构革新
基于 MSHA 将导购业务革新为“异地多读”。
多活革新 & MSHA 接入：
- 分区维度：应用 userId 来作分流标识。
- 革新范畴：将导购链路相干的入口 WEB 利用、商品利用 进行两地区部署。
- 管控配置：进入 MSHA 控制台进行各层多活资源的配置。
3）故障复现
容灾架构革新实现后，并没有完结，还需验证容灾能力是否合乎预期。接下来咱们将历史故障进行复现，通过制作实在的故障来验证容灾恢复能力。
【演练筹备】
业务监控指标：基于 MSHA 流量监控或其余监控能力，确定业务稳态监控指标，以便在故障产生时判断故障影响面以及在故障复原后判断业务的理论复原状况。
演练预期：
- 导购链路对购物车利用是弱依赖（导购页会展现用户放入购物车的商品数量），弱依赖故障不影响业务。
- 导购链路对商品利用是强依赖，强依赖故障将导致业务不可用，故障的爆炸半径应该管制在单元内。
【故障演练】
利用 AHAS-Chaos 故障演练性能，可能不便的进行多种故障场景的演练。
第一阶段：弱依赖故障演练
-
故障注入：对购物车利用进行故障注入
- 预期：导购业务不受影响
- 后果：导购页能失常关上，合乎预期
第二阶段：强依赖故障演练
演练前配置的路由规定如下（userId%10000 后依据如下路由范畴规定进行匹配）：
-
故障注入 ：对 北京单元 的商品利用进行故障注入
- 预期：userId=6000 的用户路由到北京单元，会受故障的影响
- 后果：导购页拜访异样，合乎预期
-
爆炸半径验证：验证保障半径是否管制在故障单元内
- 预期：userId=50 的用户路由到杭州单元，不受北京单元故障的影响
- 后果：导购页拜访失常，合乎预期
4）切流复原
故障场景下，应用 MSHA 切流性能，验证容灾恢复能力。
-
容灾切换验证：将 userId=6000 切流到杭州单元
- 预期：切流后该用户将路由到杭州单元，不受北京单元故障的影响。
- 后果：导购页拜访失常（导购申请的理论调用链参见上面动图），容灾恢复能力合乎预期。
后续：故障撤销
- 故障注入终止
- 演练后果反馈，记录演练辨认到的危险问题
- 流量回切
- 查看稳态业务指标是否复原
3. 案例二：流水单据型业务容灾案例
1）新的故障
通过上述的革新，导购业务曾经具备抵挡 地区级 故障的能力。而订单利用大面积 故障，成为了压死订单业务的最初一根稻草。于是，下单业务的高可用架构建设，也提上了议程。
下单是典型的流水单据型业务场景，相比导购，是更为简单的读写联合业务，联合业务场景和业务容灾诉求，咱们选取了适宜业务的容灾建设计划 –“异地多活”。
2）异地多活容灾架构革新
基于 MSHA 将订单业务革新为“异地多活”。
注：下单链路强依赖购物车利用，残缺的多活容灾建设，后续还应将购物车利用也革新为“异地多活”。
多活革新 & MSHA 接入：
- 革新范畴：下单利用和订单数据库进行两地区部署。
- MSHA 接入：将下单链路的利用装置上 Agent，从而无侵入的实现 SpringCloud RPC 跨单元路由性能和数据防脏写性能。
- 管控配置：
3）故障复现
容灾架构革新实现后，接下来咱们将历史故障进行复现，通过制作实在的故障来验证容灾恢复能力。
【演练筹备】
业务监控指标：基于 MSHA 流量监控或其余监控能力，确定业务稳态监控指标。
演练预期：下单链路对订单利用是强依赖，强依赖故障影响业务不可用，且故障爆炸半径管制在单元内。
【故障演练】
演练前配置的路由规定如下（userId%10000 后依据如下路由范畴规定进行匹配）：
-
故障注入 ：对 北京单元 的订单利用进行故障注入
- 预期：userId=6000 的用户路由到北京单元，会受到故障影响
- 后果：下单异样，合乎预期
-
爆炸半径验证：验证保障半径是否管制在故障单元内
- 预期：userId=50 的用户路由到杭州单元，不受北京单元故障的影响
- 后果：下单失常，合乎预期
4）切流复原
应用 MSHA 切流性能，验证故障场景下的容灾切换能力。
-
容灾切换验证：将 userId=6000 切流到杭州单元
- 预期：切流后该用户将路由到杭州单元，不受北京单元故障的影响
- 后果：下单失常（下单申请的理论调用链参见上面动图），容灾恢复能力合乎预期。
总结
在本篇文章中，咱们介绍了 AHAS 为业务容灾提供的一大利器：MSHA 多活容灾解决方案，并联合一个电商业务，介绍了读多写少型和流水单据型 2 个典型业务场景下的容灾建设案例，给出容灾架构建设实际办法，同时联合 AHAS-Chaos 故障演练性能模仿一次实在可能产生的故障，验证容灾能力是否合乎预期。
私有云 MSHA 曾经开始公测，并已提供文中 2 个业务场景的电商业务 Demo 体验（无需开明即可体验），欢送大家申请体验。
最初想跟大家说的是，容灾建设是一个系统工程，不能欲速不达也不是一锤子买卖，须要依据业务场景、容灾诉求、技术栈、容灾估算等综合来评估和制订适合的容灾架构建设计划，欢送大家针对本身的容灾诉求和场景进行征询和交换。
延长浏览
- AHAS-MSHA 多活容灾解决方案官网文档：https://help.aliyun.com/document_detail/181717.html
- AHAS-Chaos 故障演练官网文档：https://help.aliyun.com/document_detail/90327.html
- 电商业务多活实际：https://help.aliyun.com/document_detail/184984.html
- 强弱依赖治理 & 故障演练最佳实际：https://help.aliyun.com/document_detail/185932.html
欢送钉钉搜寻群号：31623894，退出多活容灾 (MSHA) 交换钉钉群。