阿里云开源业内首个应用多活项目 AppActive，与社区共建云原生容灾标准

简介：继高可用架构团队的 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 指标，真正意义的做到不惧故障。

原文链接

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