![点击分享此内容可以赚币 分享](/master/images/share_but.png)
应用多活技术白皮书.pdf
《应用多活技术白皮书.pdf》由会员分享,可在线阅读,更多相关《应用多活技术白皮书.pdf(39页珍藏版)》请在咨信网上搜索。
1、3234156784第一章 应用多活的起源1.1 容灾成为企业上云和用云的基础要求1.2 灾备容灾的局限性1.3 应用多活:以应用为中心的云原生容灾架构1.3.1 应用多活的概念1.3.2 应用多活的优势1.4 阿里巴巴的应用多活之路1.4.1 集团阶段1.4.2 云化阶段第二章 应用多活的典型架构2.11同城场景的应用多活2.21异地场景的应用多活2.3 混合云场景的应用多活第三章 应用多活的技术分析 3.1 应用多活的课题研究3.1.1 应用多活解决的技术问题3.1.2 应用多活领域的研究状况3.2 应用多活的设计标准3.3 应用多活的技术方案第四章 应用多活的技术原理4.1 应用层技术原
2、理4.1.1 接入网关实现原理4.1.2 微服务组件实现原理4.1.3 消息组件实现原理4.2 数据层技术原理4.3 云平台技术原理第五章 应用多活的管理策略5.1 应用多活的投入产出比5.1.1 应用多活的收益5.1.2 应用多活的成本管理5.1.3 投入产出比分析5.2 应用多活的能力保鲜第六章 应用多活的实践案例6.1 同城应用多活行业案例6.2 异地应用多活行业案例6.3 混合云应用多活行业案例第七章 应用多活的未来展望7.1 混合云多活将成为客户上云的关键决策点7.2 应用多活成为云原生容灾领域的新标准7.3 分布式云场景的应用多活7.4 AIOps 加持的应用多活7.5 多云多芯的
3、应用多活附录:名词术语第一章 应用多活的起源51.1 容灾成为企业上云和用云的基础要求2019 年 IDC 发布的全球云计算 IT 基础设施市场预测报告显示:2019 年全球云上的 IT 基础设施占比超过传统数据中心。越来越多企业因为云计算低成本、稳定性而选择在云端构建系统,云已经变成了一个主流 IT 基础设施。近年来,开源技术和云技术保持高速发展,出现种类繁多的产品和服务,技术人员决策权变大,架构更迭速度日益加快。在高速演进的过程中,要谨防人为的不合理故障,同时也要关注自然灾害的影响。一次不恰当业务中断,可能带来严重的品牌、客户、经济损失。所有的上云企业都把容灾系统能力建设作为最基础目标来要
4、求,并保证投入。只有确保灾难发生时,关键数据不丢失,系统服务尽快恢复运行,企业才能保证长久、平稳的高速发展。1.2 灾备容灾的局限性灾备容灾建立在数据级容灾的基础之上,常用的实现方式是在备份机房构建一套相同的应用系统,灾难发生时会在约定的时间范围(RTO)内恢复运行,尽可能减少灾难带来的损失。在实际实施时,存在以下几个问题:灾备中心平时不提供服务,在切换到灾备中心的关键时刻时无法确定是否可以成功切换。灾备中心平时不提供服务,整个灾备资源会处于闲置状态,成本浪费比较高。灾备中心平时不提供服务,所以平时提供服务的机房还停留在单地域,当业务体量大到一定程度时,这种模式无法解决单地域资源瓶颈的问题。6
5、图 1-1“同城灾备架构”和“异地灾备架构”示意图1.3 应用多活:以应用为中心的云原生容灾架构1.3.1 应用多活的概念“应用多活”是“应用容灾”技术的一种高级形态,指在同城或异地机房建立一套与本地生产系统部分或全部对应的生产系统,所有机房内的应用同时对外提供服务。当灾难发生时,多活系统可以分钟级内实现业务流量切换,用户甚至感受不到灾难发生。阿里巴巴的“同城多活架构”和“异地多活架构”(代号“单元化”)都是典型的应用多活实现技术。图 1-2 阿里巴巴“同城多活架构”和“异地多活架构”示意图71.3.2 应用多活的优势分钟级 RTO:恢复时间快,阿里内部生产级别恢复时间平均在 30s 以内,外
6、部客户生产系统恢复时间平均在 1 分钟。资源充分利用:资源不存在闲置的问题,多机房多资源充分利用,避免资源浪费。切换成功率高:依托于成熟的多活技术架构和可视化运维平台,相较于现有容灾架构,切换成功率高,阿里内部年切流数千次的成功率高达 99.9%以上。流量精准控制:应用多活支持流量自顶到底封闭,依托精准引流能力将特定业务流量打入对应机房,企业可基于此优势能力孵化全域灰度、重点流量保障等特性。1.4 阿里巴巴的应用多活之路1.4.1 集团阶段在 2007-2010 年期间,阿里巴巴采用同城多活架构保障在线业务的高可用。同城多活架构能够抵御机房级故障,即:同城任一机房发生故障,其他机房都具备实时接
7、管能力。但是同城架构存在地域单点的隐患。2013 年,随着业务规模的逐年攀升,阿里巴巴面临杭州机房容量不足的问题。与此同时,杭州的夏天大约持续了 1 个月 40高温,机房全天 24 小时空调不间断的工作,持续高温用电量飙升让机房存在被限电的风险。如果断电情况发生,对业务将是直接跌 0 的影响,阿里工程师就在每天的惊心吊胆中度过了这异常“Hot”的 1 个月。在容量和灾难的双重压力下,阿里工程师开始发起内部代号单元化的异地多活项目,提出1 年验证,2年双活,3 年多活的目标。2013 年,阿里工程师在杭州同城两个机房完成多活技术可行性论证。2014 年,为了保障技术的稳定演进,工程师挑选距离杭州
8、相对较近的上海进行生产双活试点,成功构建杭州和上海两地异地双活架构,阿里正式成为业内第一个具备异地多活的企业。2015 年,在具备 2 年双活成熟实践经验的基础上,阿里工程师开始探索多个数据中心多活的技术可行性,攻坚多单元梳理、改造、数据同步、运维等一系列难关,生产业务部署在千里之外的三地四中心,具备生产级别可用的异地多活能力。2017 年,异地多活构建的多单元成为阿里的基础设施,阿里多个新兴技术均依托多活能力进行生产规模化的测试验证。同年双十一,阿里工程师为支撑业务提出在双十一凌晨切流的目标,如何在减少在线业务流量影响面下更快更稳的流量切换成为多活重大的挑战。8图 1-3 阿里应用多活发展之
9、路2017 年,异地多活支撑双十一平稳进行数据中心流量调度数次,意味着在已有的日常稳定性保障基础上,异地多活已具备大促时期流量无损的秒级切换能力。1.4.2 云化阶段2019 年年初,阿里巴巴 CTO 行癫提出在 2019 年阿里巴巴核心系统全面上云的目标,与此同时,外部企业在稳定性的挑战下,提出希望阿里对外输出成熟的多活架构经验的需求。阿里工程师为服务集团上云应用和外部客户,将多年沉淀的多活技术产品孵化上云,以阿里云云产品的形态服务阿里巴巴集团和外部客户,以丰富多样的多活架构支撑不同的业务形态。在 2019-2021 年期间,应用多活云产品(AHAS-MSHA)先后帮助数字政府、物流、能源、
10、通信、互联网等十余家不同行业中的大型企业成功构建应用多活架构,基于大型企业的行业经验,应用多活进一步演进出混合云多活等一系列新特性。2022 年初,随着企业对容灾诉求日益强烈的诉求增强,应用多活的发展需要更多的组织和人介入共建,推动应用多活的发展。阿里工程师正式把多活架构代码对外开源,命名为 AppActive,希望和社区企业、开发者共建多活生态和能力,在阿里多年应用多活经验的基础上,结合社区的需求和贡献,帮助企业构建高可用架构。第二章 应用多活的典型架构92.1 同城场景的应用多活图 2-1“同城应用多活架构”示意图同城应用多活对应用系统的代码侵入较小,基于灵活的流量调度和单元格间的流量路由
11、,能做到故障场景下的业务快速恢复,实现业务恢复与故障恢复的解耦。同城应用多活,顾名思义就是分布在同城多个机房内的应用同时对外提供服务。同城机房物理距离较小(物理距离小于 100 公里)。同城场景下多机房的网络、服务互通,某机房局部故障会影响到全局,爆炸半径不可控。应用多活架构的难点,在于机房之间的流量路由和隔离。当某机房出现故障,可以做到机房级的快速切换。更精细化的场景,如果是某中心内某应用的故障,还需要做到应用级的切换。为了实现机房间的流量调度,同城应用多活架构下,建立多个服务部署的逻辑区,这个逻辑区称之为单元格(Cell)。每个单元格内的业务流量尽可能的在本区域内调用优先。由于同城跨机房
12、RT 较小,因此多个单元格的云服务采用单集群模式,从而可以避免数据一致性上的复杂度。同城应用多活的架构如下图所示:102.2 异地场景的应用多活图 2-2“异地应用多活架构”示意图同城近距离的容灾建设难以抵御地域级别的灾难,参考银行业的容灾标准,灾备中心建设都要求满足“三不原则”(即:灾备中心与生产中心不应设立在同一地震带,同一江河流域,同一电网),因此异地灾备中心一般距离生产中心 300 公里以上。异地应用多活,顾名思义就是分布在异地多个机房内的应用同时对外提供服务。在异地超远距离的场景下建设应用多活,最大的挑战在于超远距离带来的网络延迟。由于网络延迟大,云服务很难跨地域的以单集群的模式提供
13、服务,而多集群模式下会带来数据一致性的复杂度。为了解决单集群无法突破物理距离限制的问题,阿里提出了“单元化”方案。核心思路是对数据进行分片,通过自上而下的流量路由,让特定分片的数据到特定中心完成读写,以此解决数据一致性的问题,并在此基础上解决了业务的容灾和水平扩展问题。这个可以水平扩展的逻辑中心称为单元(Unit)。单元分为两种类型,中心单元与普通单元。单元内部署的业务分为三种类型,全局业务、核心业务、共享业务。中心单元只有一个,部署全局业务、核心业务、共享业务。普通单元部署核心业务、共享业务,普通单元具备水平的扩展能力,可以任意复制。全局业务:强一致性的业务,在中心单元写,在中心单元读。核心
14、业务:做单元化拆分的业务,在普通单元写,在普通单元读。共享业务:被核心业务高频依赖的全局业务读服务,在中心单元写,在普通单元读。112.3 混合云场景的应用多活混合云融合了公有云、私有云、托管私有云、边缘计算节点等不同部署模式,面向企业云上基础架构、中间件、开发全生命周期和/或应用平台的各种能力需求,为云上开发、构建、运维、运营、管控等各种技术与业务实践提供支持。IDC 报告中显示 2021 年有 14%的客户会单独选择公共云,86%企业采用多云混合云架构。混合云应用多活,顾名思义就是分布在混合云环境的应用均对外提供服务。混合云应用多活架构是在多云和异构场景衍生的容灾架构方案,将业务恢复和云基
15、础架构、云服务解耦。混合云多活管理产品对开发者和上层用户屏蔽混合云容灾的复杂度,提供一致的开发、运维、运营体验。混合云应用多活,最大的挑战在于多云独立和多云异构,做到多云集成和数据互通。多云集成,即集成多云的账号、权限、资源、数据,在此基础上构建统一的多云操作界面。数据互通,即多云的基础架构、异构的中间件体系,需要做到互相发现、互相同步,在此基础上实现数据的容灾。为了实现多云集成与数据互通,混合云多活管理需要有多云适配来屏蔽底层的差异,主要依靠三大核心功能:云服务接口适配,对下通过插件化支持多云适配,对上提供统一的云服务接口。数据模型适配,对云的账号、权限、资源、数据进行抽象,屏蔽多云的数据差
16、异。统一容灾接口,提供标准化的容灾定义和接口,利于异构云异构技术栈的快速接入。图 2-3“混合云应用多活架构”示意图第三章 应用多活的技术分析12 容灾指标在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)最多只能同时实现两点,不可能三者兼顾。在容灾场景下,多数系统选择 AP 或 CP 模式。3.1 应用多活的课题研究3.1.1 应用多活解决的技术问题多站点生产系统同时对外提供访问,RPO0 或 RPO=0,应用多活 RTO=应用灾备 RTO。3.1.2 应用多活领域的研究状况典型架构容灾模式衡量指标同
17、城双活CP 模式RPO=0,RTO 分钟级别异地多活AP 模式RPO 0,RTO 秒或分钟级别异地多活CP 模式RPO=0,RTO 分钟级别表 3-1 容灾架构的不同模式 容灾距离可用性代表系统在某个考察时间是可以正常运行或提供服务。描述一个系统可用性的常用指标有响应时间和错误率。不同系统的响应时间有所不同,从用户体感和客户端访问视角都会有某个超时阈值。对于跨地域数据同步的情况,数据库同步复制和异步复制的模式。数据库同步复制会带来一定的响应时间上升。当数据站点距离较远时,响应时间会超过阈值,请求成功率会大幅下降。13 容灾平台企业应用可以选择云产品构建生产系统,技术涉及中间件(Middlewa
18、re PaaS)、数据库(Database PaaS)、基础设施(IaaS)。在当前的情况下,云厂商间的应用编程接口(API)暂无统一标准。对于混合云多活架构,需要通用平台,为上层业务屏蔽运维和管控的差异性。应用多活领域的实现难点 流量路由一致性从可用性角度,所有业务请求均能够在可接受的时间内有所响应,并且请求质量不随着机房的物理距离和云平台设施的不同而改变。因此就需要从入口流量开始,每一层技术组件都能够识别、纠错流量,减少不合理的跨机房、跨地域调用带来的访问延迟。数据读写一致性从一致性角度,所有业务数据都要在可接受(客户有体感前)时间内保持数据正确性,即:短暂数据延迟及没有数据错乱。因此就需
19、要数据层具备单集群和跨集群同步的能力。对于跨集群异步同步的场景,极端场景下可能存在数据不一致的问题,上层数据层组件要提供面向业务的容错方案。多活运维一致性从容灾平台角度,所有容灾操作都要有标准化操作流程和预期效果。容灾平台需要有通用的服务接口、数据模型、容灾接口,帮助业务屏蔽底层云平台异构的问题。3.2 应用多活的设计标准应用多活定位是一套支持跨地域、跨平台的通用多活架构方案。应用多活架构的标准架构,需要满足以下 4 个设计标准:业务流量多活(BFA,Business Flow Active):应用多活的最终呈现是业务,多活容灾系统具备按照业务特征进行生产流量的精细化调配。同城多活(LRA,L
20、ocal Region Active):应用是分布式系统的最小服务集合,当主中心出现问题进入容灾态时,要具备全局或局部应用的多活切换能力。异地多活(UDA,Ultra Distance Active):在超远距离(机房间距超过 300 公里)时,业务系统仍具备较好的访问性能。进入容灾态时,RTO、RPO 在分钟级。14混合云多活(HCA,Hybrid Cloud Active):向上对业务屏蔽容灾细节,提供统一的多活编程范式。向下对云平台技术保持兼容,支持公有云、私有云、托管私有云、边缘计算节点等不同部署模式的多活场景。图 3-1 应用多活架构设计标准3.3 应用多活的技术方案应用多活的技术方
21、案,我们一般分为三部分,分别为应用层、数据层和云平台。三部分组件遵循应用多活的设计标准,支撑应用构建应用多活架构能力。应用层是业务应用流量主经的链路,基本构成可分为三部分:接入网关:接入网关作为业务流量打入机房的第一跳,负责应用多活入口流量的识别和分发,具备机房路由和应用路由两个核心能力。微服务:业务流量在机房内部和跨机房的同步调用方式,一般有 Consumer、Provider、注册中心等角色,具备流量路由、流量保护、故障隔离三个核心能力。消息:业务流量在机房内部和跨机房的异步调用方式,基于消息削峰填谷,一般有 Producer、Consumer、Broker 等角色。数据层涵盖业务应用数据
22、读写、数据存储和数据同步,其具备流量路由、数据一致性保护、数据同步三个核心能力。云平台是支撑业务应用运行的核心基石,基本构成覆盖单云、单机房、多云、混合云等形态。15图 3-2 应用多活的整体技术方案依托于应用层、数据层和云平台三部分应用多活的具体技术实现,企业可快速支撑业务实现应用多活容灾架构。第四章 应用多活的技术原理164.1 应用层技术原理4.1.1 接入网关实现原理一次流量请求,从移动端或 PC 端发起调用,到进入业务应用的整个流量链路过程中,我们期望尽早进行路由纠错,从而大大减少下游进行路由纠错和不必要的跨机房调用的次数。DNS 域名解析是最早的一个环节,但 DNS 仅支持按权重随
23、机分流,无法满足应用多活架构流量灵活路由的需求。HTTPDNS 具备自定义路由规则的能力,但 HTTPDNS 也存在着不适用于 PC 端流量的局限性。综上所述,应用多活架构需要在机房入口处部署一套流量接入网关,来负责七层流量的灵活路由。核心能力接入网关核心能力可以概况为:机房粒度流量路由:比例分流:支持根据一定的比例规则,将流量分流到不同机房。路由纠错:支持从流量请求中提取携带的业务标识,并根据一定的路由规则,将流量路由纠错到正确的机房。应用粒度流量路由:支持根据流量属性按照一定映射规则,将流量路由到不同的后端应用。工作模式接入网关在技术架构设计时,存在单集群和多集群两种模式。单集群模式,接入
24、网关集群对外提供一个统一接入点。流量进入网关后集群后,按照一定的路由规则将业务流量调度到相应机房内的应用。当某机房发生故障时,可以通过修改接入网关的流量规则,从而将故障机房流量切换到其他正常机房,实现故障机房流量切 0。17图 4-1 接入网关组件多活实现原理(单集群)多集群模式,每个接入网关集群对外提供一个统一接入点,使用 DNS 按权重解析访问到不同的网关集群。多个网关集群均按照相同一致的的流量规则进行路由纠错。当某机房发生故障时,通过修改所有网关集群的流量路由规则,将故障机房的流量切换到其他正常机房。若故障影响到了接入网关集群,则还需要调整 DNS 权重来将故障机房整体流量切 0。图 4
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 应用 技术 白皮书
![提示](https://www.zixin.com.cn/images/bang_tan.gif)
1、咨信平台为文档C2C交易模式,即用户上传的文档直接被用户下载,收益归上传人(含作者)所有;本站仅是提供信息存储空间和展示预览,仅对用户上传内容的表现方式做保护处理,对上载内容不做任何修改或编辑。所展示的作品文档包括内容和图片全部来源于网络用户和作者上传投稿,我们不确定上传用户享有完全著作权,根据《信息网络传播权保护条例》,如果侵犯了您的版权、权益或隐私,请联系我们,核实后会尽快下架及时删除,并可随时和客服了解处理情况,尊重保护知识产权我们共同努力。
2、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据,平台无法对文档的真实性、完整性、权威性、准确性、专业性及其观点立场做任何保证或承诺,下载前须认真查看,确认无误后再购买,务必慎重购买;若有违法违纪将进行移交司法处理,若涉侵权平台将进行基本处罚并下架。
3、本站所有内容均由用户上传,付费前请自行鉴别,如您付费,意味着您已接受本站规则且自行承担风险,本站不进行额外附加服务,虚拟产品一经售出概不退款(未进行购买下载可退充值款),文档一经付费(服务费)、不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
4、如你看到网页展示的文档有www.zixin.com.cn水印,是因预览和防盗链等技术需要对页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有水印标识(原文档上传前个别存留的除外),下载后原文更清晰;试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓;PPT和DOC文档可被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;PDF文档不管是原文档转换或图片扫描而得,本站不作要求视为允许,下载前自行私信或留言给上传者【Stan****Shan】。
5、本文档所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用;网站提供的党政主题相关内容(国旗、国徽、党徽--等)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
6、文档遇到问题,请及时私信或留言给本站上传会员【Stan****Shan】,需本站解决可联系【 微信客服】、【 QQ客服】,若有其他问题请点击或扫码反馈【 服务填表】;文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“【 版权申诉】”(推荐),意见反馈和侵权处理邮箱:1219186828@qq.com;也可以拔打客服电话:4008-655-100;投诉/维权电话:4009-655-100。