共计 3564 个字符，预计需要花费 9 分钟才能阅读完成。
作者：中西（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 等角色，具备流量路由、流量爱护、故障隔离三个外围能力，防止音讯错投导致的数据脏写，爱护切流期间音讯不丢。
- 数据层：涵盖业务利用数据读写、数据存储和数据同步，其具备流量路由、数据一致性爱护、数据同步三个外围能力。
管控立体外围涵盖多活容灾规定的日常运维和劫难场景的流量切换。
以后 AppActive 处于 v0.1 版本，开源：
- 上述的数据立体所有层的定义根底实现。
- 接入层网关的 Nginx 插件实现。
- 服务层 Dubbo2.x 插件实现。
- 数据层开源 MySQL 插件实现。
- 管控立体流量切换的根底能力。
开发者可基于 v0.1 的能力，进行 利用多活的基本功能运行和验证。
AppActive 后续布局
- 丰盛接入层、服务层、数据层插件，反对更多技术组件到 AppActive 反对的列表中。
- 减少音讯层的插件实现，反对音讯利用多活能力。
- 减少其余层在利用多活的规范和实现。
- 反对 Web 白屏化，follow 利用多活 UDA 的规范，晋升 RTO。
- 遵循利用多活 HCA 规范反对混合云多活状态。
- 遵循利用多活 LRA 规范反对同城多活状态
终点
“异地多活”和“单元化”源于阿里，也受到了业界的认可。阿里也始终心愿利用多活的产品生态能够做到规范和凋谢，对业界做出奉献。
基于利用多活的规范技术，业务利用在不同的云厂商之间，不同的基础设施之间，不同的芯片之间都能够实现互通互联。业务利用在资源充分利用的同时，达到分钟级甚至秒级的 RTO 指标，真正意义的做到不惧故障。
明天，AppActive 开源的第一个版本只是利用多活畛域的一个终点，欢送大家参加进来一起共建利用多活生态。想要理解更多 AppActive，钉钉搜寻群号：34222602，退出 AppActive 开源探讨群参加探讨吧！
点击 此处 ，立刻返回下载《利用多活技术白皮书》。
