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

2022/1/20 6:44:02

编程Tag： 应用开源流量机房容灾多活 AppActive

本文主要是介绍阿里云开源业内首个应用多活项目 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. 业务流量多活（BFABusiness 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 等角色，具备流量路由、流量保护、故障隔离三个核心能力，避免消息错投导致的数据脏写，保护切流期间消息不丢。
数据层：涵盖业务应用数据读写、数据存储和数据同步，其具备流量路由、数据一致性保护、数据同步三个核心能力。

管控平面核心涵盖多活容灾规则的日常运维和灾难场景的流量切换。