其他分享
首页 > 其他分享> > 异地多活之企业架构案例

异地多活之企业架构案例

作者:互联网

此文转载自:https://my.oschina.net/yunqi/blog/4767332
大咖揭秘Java人都栽在了哪?点击免费领取《大厂面试清单》,攻克面试难关~>>> 简介: 异地多活之企业架构案例

image.png

1. 前言

多活容灾 MSHA(Multi-Site High Availability),是在阿⾥巴巴电商业务环境演进出来的多活容灾架构解决⽅案,可以将业务恢复和故障恢复解耦,有基于灵活的规则调度、跨域跨云管控、数据保护等能力,保障故障场景下的业务快速恢复,助⼒企业的容灾稳定性建设。
多活,顾名思义就是分布在多个站点同时对外提供服务。与传统的灾备的最主要区别就是多活里的所有站点同时在对外提供服务,不仅解决了容灾本身问题,还提升了业务连续性,并且实现了容量的扩展。
本文结合实际案例来阐述下企业接入多活的架构变化,下文的逻辑业务中心均简称为“单元”。

1.png
图1:企业接入多活的架构变化

2. 架构案例

2.1 异地双读

2.1.1 客户背景

国家某政府机构的专有云大数据项目在云平台建设完成后,随着业务规模的不断增长,数据量级不断突破预期上线,客户的 ADB服务压力随之增大。在新业务逐个上线的过程中,客户开展实时数据分析常出现 ADB资源不足的情况,影响线上业务稳定性。
由于客户本身建立两个数据中心,前期因为 RT 问题,仅使用一个数据中心,另外一个并未投入使用。客户期望充分发挥两个中心的计算资源,基于 MSHA 容灾解决方案构建“异地双读”体系,以达到保障基于 ADB数据库的各类查询业务稳定性的目的。

2.1.2 方案落地

2.1.2.1 选取分区维度

基于实际业务流程,分析得到查询业务存在核心操作人员,操作人员登录系统后,进行基础业务操作行为,确定两种分片方式进行选型考虑,分别为“按分流标识分流”和“按功能URI分流”。
按分流标识分流
根据实际流量请求中携带的分流标识进行分流,是异地双活解决方案里的标准方案。业务按照自身实际情况选取合适的分流标识。
原则上选取尽可能分摊均衡的维度进行分流,便于后续动态灵活调控不同数据中心比例。比如:

按分流标识分流的优点为灵活可控,可以通过切流进行精细的流量调控。但也需要关注以下问题:

按功能 URI 分流
根据 URI 前缀进行分流,比如某域名的流量存在80个 URI ,将其中40个分流到单元A,另外40个分流到单元B。
按功能 URI 分流的优点是业务无需改造,仅需梳理出所有 URI 即可,但也存在以下问题:

最终选型
经过跟客户深度沟通交流,由于当前业务操作均按省维度进行登录操作,改造成本小且不存在一个超大占比的省份,因此选择“按分流标识分流”的方式并按省作为分流标识。

2.1.2.2 方案计划

基于确定的分区维度,双活项目组指定详细的落地计划,大致分为前期准备、业务改造、测试实施、生产实施、技术交流等步骤环节。

2.png
图2:双活项目组指定详细的落地计划

2.1.2.3 架构演进

由于方案确定之时,客户两个云平台版本一个为 3.5.x,一个为 3.9.0,而相应的多活产品(MSHA)对云平台有版本要求,仅其中一个符合要求。考虑业务的高可用能力,我们确定分阶段进行,逐步让业务具备异地双读能力。

阶段一:仅在符合要求的云内部署多活产品(MSHA)

优势:

劣势:

劣势解决方案:

 

3.png
图3:仅在符合要求的云内部署多活产品(MSHA)

阶段二:两朵云均部署多活产品(MSHA)

优势:在阶段一具备的优势前提下,规避了其劣势,保障了灾难场景时,多活产品自身高可用能力,进一步提高业务的抗风险能力。

4.png
图4:两朵云均部署多活产品(MSHA)

2.2 异地双读

2.2.1 客户背景

国家某政府机构的在线业务云平台当前采用单中心单节点的部署模式,集中在同一栋楼中,核心在线业务存在“单点”运行的安全隐患:

云平台承载的在线业务系统直接关系到国计民生,影响重大,一旦出现数据篡改丢失和系统长期无法访问,后果难以承受。为落实各项安全整改建议,确保数据安全、万无一失,客户期望在原有的数据中心云平台之外,再建设“异地双活”第二中心,基于“异地双活”解决方案能力,提高核心业务的业务连续性。

2.2.2 方案落地

上文详细介绍分区维度和方案计划,此案例简要描述,重点在业务改造接入落地。

2.2.2.1 选取分区维度

核心业务进行双活建设的时候,客户梳理其核心的业务职能可分为终端用户和政府机关两部分分流标识,二者均可以为唯一分流标识进行分流。

因此,最终选择“终端用户”为分流标识。

2.2.3 架构演进

 

5.png
图5:架构演进

基于双活解决方案,核心业务的部署模型分为如下三层。

2.2.3.1 接入层

2.2.3.2 应用层

基于阿里云 EDAS-HSF 框架和 CSB 云服务总线基础能力,多活产品新增多活插件用于处理单元封闭逻辑,支撑政府机构核心分流业务流量单元内自封闭,数据最终一致的业务跨单元请求到中心单元。

日常场景。保障“终端用户”流量在单元内发送的消息自闭环在单元内消费,其他流量产生的消息在中心单元被消费,兼容业务原有的消费体系。
切流场景。为保障消息不丢失,基于消息同步、重置位点、多活管控等核心能力使得用户流量到新单元后,原有单元堆积的消息不丢失,在新单元继续消费。

2.2.3.3 数据层

数据层设计遵循CAP理论的保AP模型,什么是 CAP,可以简单概括为:

  基于当前业务特性,高可用对于业务来说是至关重要的,同时随着数据量的增长,分区也难以避免,因此我们对于强一致做了让步,允许数据最终一致性而放弃强一致性。
  在双活场景中,各个单元按照指定的规则承担不同比例的流量写入和读取,同时中心会通过 dts 同步部分数据到各个单元,使得单元具备快速的业务恢复能力,当某个单元出现任何异常不可用场景时,业务流量随时可以切换到其余冗余当前单元数据的正常单元,保障了业务可持续性和稳定性。

2.3 改造成本

方案实施期间,客户的改造成本集中在数据平面的代码依赖及流量染色、管控平面的双活资源接入管理上,概述如下图。

6.png
图6:客户改造成本简要介绍

3. 后记

本文案例中描述的异地多活产品-MSHA,2019 年基于阿里集团异地多活体系孵化而出,2020年先后在国家某政府机构、某头部运营商新客服等客户生产落地,混合云及公有云产品均对外商业化中,有容灾高可用相关诉求的客户欢迎咨询和试用。

 


原文链接
本文为阿里云原创内容,未经允许不得转载。

标签:架构,标识,业务,URI,分流,异地,多活,单元
来源: https://www.cnblogs.com/phyger/p/14068801.html