晋城市网站建设管理人员,软件定制网,太原做网站的鸣蝉公司,好的h5网站简介#xff1a;继高可用架构团队的 Sentinel、Chaosblade 开源后#xff0c;第三个重磅高可用产品#xff1a;应用多活 AppActive 正式开源#xff0c;形成高可用的三架马车#xff0c;帮助企业构建稳定可靠的企业级生产系统#xff0c;提高企业面对容灾、容错、容量等问…简介继高可用架构团队的 Sentinel、Chaosblade 开源后第三个重磅高可用产品应用多活 AppActive 正式开源形成高可用的三架马车帮助企业构建稳定可靠的企业级生产系统提高企业面对容灾、容错、容量等问题的稳态系统建设能力。
作者中西github zhongxigAppActive 负责人来自阿里云云原生高可用架构团队从事容灾架构和故障快恢的研发和开源工作。
摘要继高可用架构团队的 Sentinel、Chaosblade 开源后第三个重磅高可用产品应用多活 AppActive 正式开源形成高可用的三架马车帮助企业构建稳定可靠的企业级生产系统提高企业面对容灾、容错、容量等问题的稳态系统建设能力。1 月 11 日在上海的云原生实战峰会上阿里云智能研究员丁宇发布了“应用多活技术白皮书”同时为了推动业界容灾的发展建立云原生业务容灾标准阿里云对外开源“应用多活”中间件AppActive。 什么是 AppActive
“业务大规模扩展机房资源不可用怎么办机房挂了怎么办业务突然奔溃怎么办台风地震导致断电怎么办”
2013 年当时淘宝完成去 O 没多久双十一的规模较上年进一步飞增。阿里的工程师正面临着上述的这一系列问题一方面是机房资源非常紧张容量不足另一方面是杭州出现罕见的高温天气机房面临断电的风险。异地多活架构在这个背景下孵化出来它的载体是集团版本的 UnitRouterUnitBrain 。
随着淘宝的业务规模演进异地多活也从近距离同城双机房到远距离异地双活再到三地四单元、多地多活沉淀了丰富的机房级应用多活经验。
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. 业务流量多活BFABusiness Flow Active
BFA指的是应用多活的最终呈现是业务多活容灾系统具备按照业务特征进行生产流量的精细化调配。 AppActive 在 BFA 指标中支持流量自动纠偏强路由到指定机房自闭环属于流量的精细化调配。
在非法流量打入机房时机房的各层插件均会依托于统一的调度规则进行处理
接入层识别错误流量自动纠错到正确的机房。服务层识别错误流量自动纠错到正确的机房。数据层识别错误流量为保证数据质量抛出异常写入失败。
2. 异地多活UDAUltra 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 指标真正意义的做到不惧故障。
原文链接
本文为阿里云原创内容未经允许不得转载。
