7
1.3.2 应用多活的优势
分钟级 RTO:恢复时间快,阿里内部生产级别恢复时间平均在 30s 以内,外部客户生产系统恢复时间
平均在 1 分钟。
资源充分利用:
资源不存在闲置的问题,多机房多资源充分利用,避免资源浪费。
切换成功率高:依托于成熟的多活技术架构和可视化运维平台,相较于现有容灾架构,切换成功率高,
阿里内部年切流数千次的成功率高达 99.9%以上。
流量精准控制:
应用多活支持流量自顶到底封闭,依托精准引流能力将特定业务流量打入对应机房,
企业可基于此优势能力孵化全域灰度、重点流量保障等特性。
1.4 阿里巴巴的应用多活之路
1.4.1 集团阶段
在 2007-2010 年期间,阿里巴巴采用同城多活架构保障在线业务的高可用。同城多活架构能够抵御机房
级故障,即:同城任一机房发生故障,其他机房都具备实时接管能力。但是同城架构存在地域单点的隐
患。
2013 年,随着业务规模的逐年攀升,阿里巴巴面临杭州机房容量不足的问题。与此同时,杭州的夏天大
约持续了 1 个月 40℃高温,机房全天 24 小时空调不间断的工作,持续高温用电量飙升让机房存在被限
电的风险。如果断电情况发生,对业务将是直接跌 0 的影响,阿里工程师就在每天的惊心吊胆中度过了
这异常“Hot”的 1 个月。
在容量和灾难的双重压力下,阿里工程师开始发起内部代号"单元化"的异地多活项目,提出"1 年验证,2
年双活,3 年多活"的目标。
2013 年,阿里工程师在杭州同城两个机房完成多活技术可行性论证。
2014 年,为了保障技术的稳定演进,工程师挑选距离杭州相对较近的上海进行生产双活试点,成功构建
杭州和上海两地异地双活架构,阿里正式成为业内第一个具备异地多活的企业。
2015 年,在具备 2 年双活成熟实践经验的基础上,阿里工程师开始探索多个数据中心多活的技术可行性,
攻坚多单元梳理、改造、数据同步、运维等一系列难关,生产业务部署在千里之外的三地四中心,具备
生产级别可用的异地多活能力。
2017 年,异地多活构建的多单元成为阿里的基础设施,阿里多个新兴技术均依托多活能力进行生产规模
化的测试验证。同年双十一,阿里工程师为支撑业务提出在双十一凌晨切流的目标,如何在减少在线业
务流量影响面下更快更稳的流量切换成为多活重大的挑战。