作者：中西（github @zhongxig），AppActive 负责人，来自阿里云云原生高可用架构团队，从事容灾架构和故障快恢的研发和开源工作。
摘要： 继高可用架构团队的 Sentinel、Chaosblade 开源后，第三个重磅高可用产品： 应用多活 AppActi ve 正式开源，形成高可用的三架马车，帮助企业构建稳定可靠的企业级生产系统，提高企业面对容灾、容错、容量等问题的稳态系统建设 能力。
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 指标，真正意义的做到不惧故障。
今天，AppActive 开源的第一个版本只是应用多活领域的一个起点，欢迎大家参与进来一起共建应用多活生态。想要了解更多 AppActive，钉钉搜索群号：34222602，加入 AppActive 开源讨论群参与讨论吧！
点击此处，立即前往下载《应用多活技术白皮书》。
