1 月 11 日，在上海的云原生实战峰会上，阿里云智能研究员丁宇发布了“应用多活技术白皮书”，同时为了推动业界容灾的发展，建立云原生业务容灾标准，阿里云对外开源“应用多活”中间件：AppActive。

• 分钟级 RTO。恢复时间快，阿里内部生产级别恢复时间平均在 30s 以内，外部客户生产系统恢复时间平均在 1 分钟。

• 资源充分利用。资源不存在闲置的问题，多机房多资源充分利用，避免资源浪费。

• 切换成功率高。依托于成熟的多活技术架构和可视化运维平台，相较于现有容灾架构，切换成功率高，阿里内部年切流数千次的成功率高达 99.9% 以上。  

• 流量精准控制。应用多活支持流量自顶到底封闭，依托精准引流能力将特定业务流量打入对应机房，企业可基于此优势能力孵化全域灰度、重点流量保障等特性。

通过服务阿里集团近 9 年实战经验及服务云上客户 2 年多的商业化迭代积累，AHAS-MSHA 已经在涵盖阿里的十余家大型企业的容灾场景中落地，使用量在持续增长，代码的稳定性和功能特性也经过充分的检验。

2021 年，国内外多家知名公司、云平台出现较严重服务中断、宕机事件。这也为企业敲响警钟，越来越多的企业把容灾建设提上日程。在解决容灾问题的同时，为了保持对成本的控制、支撑未来的多云架构演进和灾难容灾的确定性，许多企业选择以多活容灾的方式进行尝试。

但是业内对于多活没有统一的认知，对于“多活”这个词不同企业有不同的定义，很多企业往往以为已经实现了“多活”，可当故障来临的时候，才发现当前系统的故障逃逸能力非常弱，业务恢复和故障定位无法解耦，拖累了企业生产，造成了外部舆情、资金损失等问题；另外，有的企业在了解“多活”之后，下意识想要企业内部先投入资源进行技术预演，但由于缺少经验，往往会造成人力物力等资源的重复浪费。随着云原生技术发展，越来越多的客户采用云原生技术进行系统构建。如何在云原生上构建稳定高可用的系统，是一个核心挑战。“多活”的认知偏差会加剧企业在基础设施成本、应用改造成本、运维成本等成本面的投入，但存在效率低下、错用甚至无用或者不用的问题，从而享受不到“多活”带来的稳定性红利。因此“多活”需要一个相对统一的标准与认知，加深使用者对它的理解和使用，从而提高业务系统的稳定性。

在当前云原生发展的现状和市场认知下，AppActive 的项目负责人中西表示，应用多活的开源和解读，可以初步定义“多活”的标准和实现，帮助开发者形成统一的“多活”认知。在企业构建多活架构时，基于应用多活共享已有的成熟经验，避免多余的资源浪费。同时，不同的企业具备不同的业务场景和优势，反向推动应用多活进一步完善和演进成熟的多活形态及能力。希望依靠社区的力量，让“多活”成为一项事实意义的普惠技术，而不是望而却步的部分人可用技术，帮助更多的企业和个人构建生产级别的高可用架构。

1. 业务流量多活（BFA，Business Flow Active）

• 接入层识别错误流量，自动纠错到正确的机房。

• 服务层识别错误流量，自动纠错到正确的机房。

• 数据层识别错误流量，为保证数据质量，抛出异常，写入失败。

2. 异地多活（UDA，Ultra Distance Active）

• 接入网关。接入网关作为业务流量打入机房的第一跳，负责应用多活入口流量的识别和分发，具备机房路由和应用路由两个核心能力。

• 服务层。业务流量在机房内部和跨机房的同步调用方式，一般有 Consumer、Provider、注册中心等角色，具备流量路由、流量保护、故障隔离三个核心能力，避免调用错误导致的数据脏写，加速切流期间的业务恢复。

• 消息层。业务流量在机房内部和跨机房的异步调用方式，基于消息削峰填谷，一般有 Producer、Consumer、Broker 等角色，具备流量路由、流量保护、故障隔离三个核心能力，避免消息错投导致的数据脏写，保护切流期间消息不丢。

• 数据层：涵盖业务应用数据读写、数据存储和数据同步，其具备流量路由、数据一致性保护、数据同步三个核心能力。

• 上述的数据平面所有层的定义基础实现。

• 接入层网关的 Nginx 插件实现。

• 服务层 Dubbo2.x 插件实现。

• 数据层开源 MySQL 插件实现。

• 管控平面流量切换的基础能力。

1. 丰富接入层、服务层、数据层插件，支持更多技术组件到 AppActive 支持的列表中。

   
   

2. 增加消息层的插件实现，支持消息应用多活能力。

   
   

3. 增加其他层在应用多活的标准和实现。

   
   

4. 支持 Web 白屏化，follow 应用多活 UDA 的标准，提升 RTO。

   
   

5. 遵循应用多活 HCA 标准支持混合云多活形态。
   
   
6. 遵循应用多活 LRA 标准支持同城多活形态