简介:继高可用架构团队的 Sentinel、Chaosblade 开源后,第三个重磅高可用产品:应用多活 AppActive 正式开源,形成高可用的三架马车,帮助企业构建稳定可靠的企业级生产系统,提高企业面对容灾、容错、容量等问题的稳态系统建设能力。
作者:中西(github @zhongxig),AppActive 负责人,来自阿里云云原生高可用架构团队,从事容灾架构和故障快恢的研发和开源工作。
摘要:继高可用架构团队的 Sentinel、Chaosblade 开源后,第三个重磅高可用产品:应用多活 AppActive 正式开源,形成高可用的三架马车,帮助企业构建稳定可靠的企业级生产系统,提高企业面对容灾、容错、容量等问题的稳态系统建设能力。
1 月 11 日,在上海的云原生实战峰会上,阿里云智能研究员丁宇发布了“应用多活技术白皮书”,同时为了推动业界容灾的发展,建立云原生业务容灾标准,阿里云对外开源“应用多活”中间件:AppActive。
什么是 AppActive
“业务大规模扩展机房资源不可用怎么办?机房挂了怎么办?业务突然奔溃怎么办?台风地震导致断电怎么办?”
2013 年,当时淘宝完成去 O 没多久,双十一的规模较上年进一步飞增。阿里的工程师正面临着上述的这一系列问题,一方面是机房资源非常紧张,容量不足,另一方面是杭州出现罕见的高温天气,机房面临断电的风险。异地多活架构在这个背景下孵化出来,它的载体是集团版本的 UnitRouter&UnitBrain 。
随着淘宝的业务规模演进,异地多活也从近距离同城双机房到远距离异地双活,再到三地四单元、多地多活,沉淀了丰富的机房级应用多活经验。
2019 年,阿里巴巴系统全面上云,异地多活架构也跟着上云的节奏孵化出阿里云云产品 AHAS-MSHA,服务集团和云上客户。
2022 年 1 月 11 日,AHAS-MSHA 代码正式开源,命名为 AppActive 。
AppActive 是一个面向业务应用构建云原生高可用多活容灾架构的开源中间件,它的主要价值:
- 分钟级 RTO。恢复时间快,阿里内部生产级别恢复时间平均在 30s 以内,外部客户生产系统恢复时间平均在 1 分钟。
- 资源充分利用。资源不存在闲置的问题,多机房多资源充分利用,避免资源浪费。
- 切换成功率高。依托于成熟的多活技术架构和可视化运维平台,相较于现有容灾架构,切换成功率高,阿里内部年切流数千次的成功率高达 99.9% 以上。
- 流量精准控制。应用多活支持流量自顶到底封闭,依托精准引流能力将特定业务流量打入对应机房,企业可基于此优势能力孵化全域灰度、重点流量保障等特性。
为什么开源
通过服务阿里集团近 9 年实战经验及服务云上客户 2 年多的商业化迭代积累,AHAS-MSHA 已经在涵盖阿里的十余家大型企业的容灾场景中落地,使用量在持续增长,代码的稳定性和功能特性也经过充分的检验。
2021 年,国内外多家知名公司、云平台出现较严重服务中断、宕机事件。这也为企业敲响警钟,越来越多的企业把容灾建设提上日程。在解决容灾问题的同时,为了保持对成本的控制、支撑未来的多云架构演进和灾难容灾的确定性,许多企业选择以多活容灾的方式进行尝试。
但是业内对于多活没有统一的认知,对于“多活”这个词不同企业有不同的定义,很多企业往往以为已经实现了“多活”,可当故障来临的时候,才发现当前系统的故障逃逸能力非常弱,业务恢复和故障定位无法解耦,拖累了企业生产,造成了外部舆情、资金损失等问题;另外,有的企业在了解“多活”之后,下意识想要企业内部先投入资源进行技术预演,但由于缺少经验,往往会造成人力物力等资源的重复浪费。随着云原生技术发展,越来越多的客户采用云原生技术进行系统构建。如何在云原生上构建稳定高可用的系统,是一个核心挑战。“多活”的认知偏差会加剧企业在基础设施成本、应用改造成本、运维成本等成本面的投入,但存在效率低下、错用甚至无用或者不用的问题,从而享受不到“多活”带来的稳定性红利。因此“多活”需要一个相对统一的标准与认知,加深使用者对它的理解和使用,从而提高业务系统的稳定性。
在当前云原生发展的现状和市场认知下,AppActive 的项目负责人中西表示,应用多活的开源和解读,可以初步定义“多活”的标准和实现,帮助开发者形成统一的“多活”认知。在企业构建多活架构时,基于应用多活共享已有的成熟经验,避免多余的资源浪费。同时,不同的企业具备不同的业务场景和优势,反向推动应用多活进一步完善和演进成熟的多活形态及能力。希望依靠社区的力量,让“多活”成为一项事实意义的普惠技术,而不是望而却步的部分人可用技术,帮助更多的企业和个人构建生产级别的高可用架构。
开源的内容
AppActive 标准介绍
在应用多活的标准定义里有 LRA(同城多活)、UDA(异地多活)、HCA(混合云多活)和 BFA(业务流量多活),详细见《应用多活技术白皮书》。在 AppActive v0.1 版本中,我们优先实现 BFA 和 UDA 的基础能力,在后续版本中完善 BFA 和 UDA 的同时,新增 LRA、HCA 能力。本文重点介绍 BFA、UDA。
1. 业务流量多活(BFA,Business Flow Active)
BFA,指的是应用多活的最终呈现是业务,多活容灾系统具备按照业务特征进行生产流量的精细化调配。
AppActive 在 BFA 指标中,支持流量自动纠偏,强路由到指定机房自闭环,属于流量的精细化调配。
在非法流量打入机房时,机房的各层插件均会依托于统一的调度规则进行处理:
- 接入层识别错误流量,自动纠错到正确的机房。
- 服务层识别错误流量,自动纠错到正确的机房。
- 数据层识别错误流量,为保证数据质量,抛出异常,写入失败。
2. 异地多活(UDA,Ultra Distance Active)
UDA,指的是在超远距离(机房间距超过 300 公里)时,业务系统仍具备较好的访问性能。进入容灾态时,RTO、RPO 在分钟级。
AppActive 在 UDA 指标中,支持访问性能良好。
在接入层支持流量解析,将请求流量进行解析,将流量打入机房的应用机器。基于 应用侧 Servlet 插件、Dubbo 插件、MySQL 插件的能力,业务流量请求在单一机房里面自闭环,最终读写到本机房的数据库。
在超远距离场景下,由于流量封闭在机房内部,因此业务系统仍旧具备较好的访问性能。
进入容灾态的 RPO 由开源数据同步组件或商业化同步工具进行保障,RTO 在 AppActive 0.1 版本中仅提供初级的流量切换能力,后续版本会演进到生产级别 RTO 保障工具。
AppActive 模块介绍
AppActive 属于应用多活的一种定义和实现,它有数据平面和管控平面的整体实现。数据平面分为 4 部分,均支持在不变更原有企业使用技术组件基础上,以插件的形式增加能力:
- 接入网关。接入网关作为业务流量打入机房的第一跳,负责应用多活入口流量的识别和分发,具备机房路由和应用路由两个核心能力。
- 服务层。业务流量在机房内部和跨机房的同步调用方式,一般有 Consumer、Provider、注册中心等角色,具备流量路由、流量保护、故障隔离三个核心能力,避免调用错误导致的数据脏写,加速切流期间的业务恢复。
- 消息层。业务流量在机房内部和跨机房的异步调用方式,基于消息削峰填谷,一般有 Producer、Consumer、Broker 等角色,具备流量路由、流量保护、故障隔离三个核心能力,避免消息错投导致的数据脏写,保护切流期间消息不丢。
- 数据层:涵盖业务应用数据读写、数据存储和数据同步,其具备流量路由、数据一致性保护、数据同步三个核心能力。
管控平面核心涵盖多活容灾规则的日常运维和灾难场景的流量切换。
当前 AppActive 处于 v0.1 版本,开源:
- 上述的数据平面所有层的定义基础实现。
- 接入层网关的 Nginx 插件实现。
- 服务层 Dubbo2.x 插件实现。
- 数据层开源 MySQL 插件实现。
- 管控平面流量切换的基础能力。
开发者可基于 v0.1 的能力,进行 应用多活的基本功能运行和验证。
AppActive 后续规划
- 丰富接入层、服务层、数据层插件,支持更多技术组件到 AppActive 支持的列表中。
- 增加消息层的插件实现,支持消息应用多活能力。
- 增加其他层在应用多活的标准和实现。
- 支持 Web 白屏化,follow 应用多活 UDA 的标准,提升 RTO。
- 遵循应用多活 HCA 标准支持混合云多活形态。
- 遵循应用多活 LRA 标准支持同城多活形态
起点
“异地多活”和“单元化”源于阿里,也受到了业界的认可。阿里也一直希望应用多活的产品生态可以做到标准和开放,对业界做出贡献。
基于应用多活的标准技术,业务应用在不同的云厂商之间,不同的基础设施之间,不同的芯片之间都可以实现互通互联。业务应用在资源充分利用的同时,达到分钟级甚至秒级的 RTO 指标,真正意义的做到不惧故障。
原文链接
本文为阿里云原创内容,未经允许不得转载。