八年来我们到底经历了什么?——中间件专家带你“重走”双11高可用架构演进之路

本文涉及的产品
Serverless 应用引擎 SAE,800核*时 1600GiB*时
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 在7月27日的首届阿里巴巴中间件技术峰会,来自阿里巴巴中间件技术部的高级技术专家周洋(中亭)带来了题为《双11高可用架构演进之路》的精彩分享。在本次分享中,他从能力大促、精细大促和效率大促三个方面探寻双11高可用架构演进之路,并对未来双11的挑战进行了展望。

双11的技术挑战

双11技术挑战的本质使用用有限的成本去是实现最大化的用户体验和集群整体吞吐能力,用最合理的代价解决零点峰值,支撑好业务的狂欢。阿里做双11已经有八年之久了,八年来双11的交易额增长200倍,交易峰值增长400多倍,系统复杂度和大促支撑难度以指数级攀升;并且经过多年的发展,双11技术实现链条中的变量不断增加,如峰值的增量和系统架构的变化、交易峰值的组成、拆单比、每个业务入口的访问量等,这些变量也给系统带来了不确定性。回顾这八年的双11零点之战,它推动了阿里的技术进步、推动了架构优化,加速了技术演进和沉淀。

阿里的技术演进是一个螺旋向上的过程,整体高可用演进可以分为三个阶段:能力大促、精细大促、效率大促,下面来一一分析。

 

能力大促——3.0分布式架构

8d6bbc72648b5aa5888c1ee4fbbcbde0ca41a817 

能力大促第一个要求是解决扩展性的问题。上图是淘宝3.0分布式架构,其意义在于让淘宝从一个集中化应用转变为分布化应用。在该架构中对业务进行了分层,同时在系统中首次使用中间件、分布式调用、分布式消息、分布式数据库;架构底层沉淀了分布式存储和缓存。目前而言,大部分互联网应用都是基于这一架构的,并且发展到现在,该架构并无太大的变化。

但随着双11业务量的增加,该架构面临着很多挑战:

(1)系统的可用性和故障恢复能力,以前集中化架构,出现问题回滚即可;现在由于涉及到众多分布式系统,快速排查和定位问题变得十分困难。

(2)分布式改造之后,单个系统存放在特定机房里,随着业务发展,机器数目的增加,机房应用层水平伸缩瓶颈、数据库链接等都成了挑战;

(3)IDC资源限制,单个城市已经不足以支撑业务的增长规模;

(4)容灾问题,单地域IDC单点、网络、台风、电力等导致高风险;

(5)国际化部署需求,可扩展性再次成为瓶颈。

c1649735443f190462bde9b295b39e0f0cd94753 

针对上述挑战,我们采用了异地多活方案,具体从四个方面出发:首先建设异地单元机房;其次由于业务中买家维度数据远多于卖家维度数据,且卖家维度数据变化并非十分频繁,因此可以将流量按用户维度进行切分;此外,由于走向异地最大的挑战是网络,为了减少异地调用的延时,必须实现业务在本单元的封闭性,减少远程调用;最后,由于容灾的需求,数据层实时同步,保持最终一致。

异地多活架构

99a57079ab9e006bd2b70afb59248a525f5fd5b0 

上图是异地多活架构,可以看出,从CDN到阿里内部的接入层都满足单元化规则,根据当前用户的ID,判断流量的出口;在下游的层层中间件上以及数据写入存储时会对用户请求进行判断,如出现异常,则报错,防止错误的数据写入。卖家的数据部署在中心,单元的数据会同步到中心,中心卖家的数据也会同步到各个单元,但在各个单元内只能对卖家的数据进行读操作。

那么异地多活的到底有什么意义呢?首先异地多活消除了IDC资源单点和容量瓶颈;其次解决了异地容灾问题,业务可以秒级快速切换;此外,异地多活简化了容量规划,提升了伸缩性和可维护性;最后,通过异地多活解决了可扩展性问题,为后续架构演进打下坚实基础。

能力大促——容量规划

c00c9c217eba952e689d525562d7e45b1bc9357f 

对于上文提到的3.0架构,单机器的极限能力乘以机器数,在下游依赖都充足的情况下,近似等于整个系统的能力。因此,当前做容量规划,首先需要评估应用线上单机极限能力;再根据公式和经验推演容量规划。

目前,在阿里内部进行容量规划时,面临以下挑战:

  • 容量规划的目的是从用户登录到完成购买的整个链条中,整体资源如何合理分配?
  • 500+的核心系统、整个技术链条长、业务入口多、逻辑复杂;
  • 链路瓶颈点较多,每年大促峰值都会出现一些问题,无法提前发现;
  • 堆积木的容量规划方法,前面失之毫厘后面谬以千里;
  • 在能力评估时应该考虑的是一个处理链路而不仅仅是单一的应用;
  • 缺乏验证核心页面和交易创建链条实际承载能力的手段。

压测方案

47416dc165757792c94f6ffc227949ac648ecb4a 

为了应对上述挑战,我们需要从全链条的角度出发进行压测和容量规划。全链路压测是在线上集群模拟真实业务流量的读写压测,完成从网络、IDC、集群、应用、缓存、DB以及业务系统上下游依赖链条的容量、性能压力测试;整体压测通过自定义压测工具,大流量来自机房外部,进而构造线上测试数据,且业务模型接近真实;全链路压测隔离了测试数据和正常数据,两者之间互不影响,并且全链路压测时是对用户体验无感知、无影响的。

06eeb02e9e4b36fa0073bb049e3398ac12a79abb 

全链路压测通过复用中间件的能力,具有超大规模的集群压测能力,每秒千万QPS;同时将压测引擎部署到全球各地的CDN上,实现了分布式部署压测引擎,按照约定的时间发送压测数据;其次,压测数据是基于线上真实数据进行了脱敏和偏移,数据模型与双11极其接近;此外,实现了线程级隔离,无脏数据,压力测试直接作用于线上集群,暴露问题更加精准。

通过全链路压测,打破了不可预知技术风险的限制,加速技术进化;为新技术的尝试和突破做好保底和验收的工作;做到了主动发现问题而不是被动等待、应急处理;通过新的线上演练,为稳定性的确定性打下坚实基础。

能力大促——限流降级

3eddb4cbd63620ef10faf79c516fc0d4272f341f 

限流降级是能力大促的必要要求。在双11开始前,尽管我们准备了大量的机器和能力,然而在双11零点到来时,真实业务量还是有可能大于我们的预期。此时,为了确保我们的机器不超负荷运作,我们采用了限流措施,超过机器极限的业务全部拒绝,避免系统因业务流量的突然过大而崩溃。目前,阿里能够做到从线程数、请求值、负载多个角度进行限流,从而保障系统的稳定。

分布式应用是默认下游应用是不可靠的,对于一些弱依赖的请求,应该进行提前自动降级。至于哪些应用需要降级?需要降级什么?下游的依赖又是什么?这些问题都是通过依赖治理来解决的。

 

精细大促——依赖治理

2a610fc01645b66492d9ec667bf3c74b52d76568 

在阿里内部,依赖治理是通过中间件分布式链路跟踪技术,完成系统架构梳理;同时对海量调用链进行统计,得到链路各个依赖系统的稳定性指标;此外,结合业务用例识别强弱依赖,弱依赖可自动降级提供有损服务。

精细大促——开关预案

1fd510dd1193ed9550ef1ff15deaabbc37c8c541 

精细化双11控制的首要机制是开关预案。开关是让系统切换不同功能表现的标准技术,可以无需变更代码只推送配置控制系统行为,让系统的后门标准化。开关中心配置变更可以实时下发到集群,且操作行为对业务而言是原子性的。开关预案整合了一批业务开关、限流等操作,将多系统的后台操作组装批量执行;实现了预案推送是有顺序性的,保证业务切换的一致性和完整性。

精细大促——故障演练

146da7c0a56c70730ffa0c17a9545928954ac9b8 

统计学的数据显示:当服务规模大于一定数量时,硬件故障无法避免。因此,系统要面向失败做设计,测试系统健壮性的最佳方法,就是不要用正常方式使服务停机。对应线上系统,要实现容灾,首先需要实现背后工具体系的容灾。由于线上故障是一种常态,系统负责人要具备快速发现和处理故障的能力,需要实战机会来成长。另外,跨团队的流程也是需要加以重视,由于业务分布式的特性,出现故障时需要业务系统的上下游共同协作,这就对流程提出来严格的要求。

故障演练的实现方案

07e30135a4b8fc4cc8447da42afe297da8c422f5 

前期,我们将阿里电商常见的故障进行画像和分析,得到初步结论,按照IaaS、PaaS、SaaS层进行初步划分,但这个模型无法完全通用,并非包含所有的故障;因此,后期我们对这一模型又进一步抽象,将故障分为进程内的故障,如代码死循环等;进程外的故障,如磁盘读写速度变慢、网络波动等;分布式调用依赖的底层设施故障,如数据库、缓存活其他设施出现故障。

目前,阿里故障演练实现了业务零改造,可插拔式接入;多维度业务识别和故障注入,定量控制演练影响;沉淀通用故障模型,平台化输出演练能力。

353f41c5378f7c64e55b1c06a3915e7f9ed02574 

从去年双11开始,阿里开始使用线上统一演练环境,通过逻辑隔离,动态扩展逻辑环境,按需租赁,简化测试步骤,使得演练结果更加真实;同时多套环境互不影响,严格保证环境的稳定和安全;支持用户、业务、数据、流量特征的分流和隔离,提高了效率,赋能业务创新。

 

效率大促——流量调度

 d380b22c6aaad3009ff17adacc2d7d08b617302c

在线上集群中,如果个别机器发生故障,为了保证业务的整体稳定性,需要对故障点进行流量调度。流量调度通过实时探测与监控分布式环境中每一台机器的状况,如果机器发生故障,则使用分布式服务具有的自我隔离和自我修复能力,使用流量调度和负载均衡机制,通过关注局部用户请求和用户体验,提升整体可用性。

 

未来挑战

尽管我们已经采用了很多措施来保障双11的稳定性,但未来,依旧面临着不少挑战:

  • 实现更加精细化、数据化、智能化的双11;
  • 从容量确定性到资源确定性,从每个实例部署在哪里最佳、精确到每个内核如何分配最佳;
  • 更加精准的分析、预测流量模型和业务模型,实现预测、引导相结合,逼近真实、增加确定性;
  • 实现技术变量的采集、分析、预测,数据分析驱动,自主决策处理,做到关键技术指标的预估错误系统做到自适应,弹性处理;
  • 在体验、成本和最大吞吐能力找到新的平衡点。


其他:

中间件高可用架构团队是阿里稳定性保障的核心团队,团队使命是构建稳定性基础设施,推动业务升级和架构改造,技术创造商业价值,机会、挑战、梦想非常大。现在招聘高可用产品研发、云产品研发的人才,如果你对我们团队感兴趣,请邮件zhongting.zy@taobao.com, 绿色通道极速面试,期待你的加入。

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
相关文章
|
2月前
|
存储 Cloud Native 关系型数据库
PolarDB 高可用架构设计与实践
【8月更文第27天】 在现代互联网应用中,数据库作为核心的数据存储层,其稳定性和可靠性尤为重要。阿里云的 PolarDB 作为一款云原生的关系型数据库服务,提供了高可用、高性能和自动化的特性,适用于各种规模的应用。本文将详细介绍 PolarDB 的高可用架构设计,并探讨其实现数据安全性和业务连续性的关键技术。
58 0
|
25天前
|
机器学习/深度学习 测试技术 数据处理
KAN专家混合模型在高性能时间序列预测中的应用:RMoK模型架构探析与Python代码实验
Kolmogorov-Arnold网络(KAN)作为一种多层感知器(MLP)的替代方案,为深度学习领域带来新可能。尽管初期测试显示KAN在时间序列预测中的表现不佳,近期提出的可逆KAN混合模型(RMoK)显著提升了其性能。RMoK结合了Wav-KAN、JacobiKAN和TaylorKAN等多种专家层,通过门控网络动态选择最适合的专家层,从而灵活应对各种时间序列模式。实验结果显示,RMoK在多个数据集上表现出色,尤其是在长期预测任务中。未来研究将进一步探索RMoK在不同领域的应用潜力及其与其他先进技术的结合。
66 4
|
1月前
|
存储 Java Maven
从零到微服务专家:用Micronaut框架轻松构建未来架构
【9月更文挑战第5天】在现代软件开发中,微服务架构因提升应用的可伸缩性和灵活性而广受欢迎。Micronaut 是一个轻量级的 Java 框架,适合构建微服务。本文介绍如何从零开始使用 Micronaut 搭建微服务架构,包括设置开发环境、创建 Maven 项目并添加 Micronaut 依赖,编写主类启动应用,以及添加控制器处理 HTTP 请求。通过示例代码展示如何实现简单的 “Hello, World!” 功能,并介绍如何通过添加更多依赖来扩展应用功能,如数据访问、验证和安全性等。Micronaut 的强大和灵活性使你能够快速构建复杂的微服务系统。
64 5
|
3月前
|
关系型数据库 MySQL Serverless
Serverless高可用架构体验评测
Serverless高可用架构作为企业业务上云不得不考虑的一种低成本高可靠的方案,已经在多领域得到了非常好的验证。希望可以通过阅读文章,让你对Serverless架构得到更深的了解。
12569 21
Serverless高可用架构体验评测
|
2月前
|
运维 监控 关系型数据库
【一文搞懂PGSQL】7. PostgreSQL + repmgr + witness 高可用架构
该文档介绍了如何构建基于PostgreSQL的高可用架构,利用repmgr进行集群管理和故障转移,并引入witness节点增强网络故障检测能力。repmgr是一款轻量级的开源工具,支持一键部署、自动故障转移及分布式节点管理。文档详细描述了环境搭建步骤,包括配置postgresql参数、安装与配置repmgr、注册集群节点以及配置witness节点等。此外,还提供了故障手动与自动切换的方法及常用命令,确保集群稳定运行。
|
2月前
|
数据挖掘 关系型数据库 MySQL
Serverless高可用架构的解决方案体验
Serverless高可用架构的解决方案体验
148 6
|
2月前
|
弹性计算 运维 关系型数据库
云上Serverless高可用架构一键部署体验与测评
在数字化转型背景下,Serverless架构因其实现业务敏捷、降低成本及提升服务可靠性而备受青睐。本文以阿里云Serverless应用引擎(SAE)为核心,展示了一种高可用、低成本且易于扩展的解决方案。通过单地域双可用区部署,构建了具备自动伸缩与故障恢复能力的架构。借助阿里云的一键部署功能,大幅简化了搭建流程,实现了快速部署,并通过性能与成本分析验证了其优势。对比传统ECS,SAE在资源利用与运维效率上表现更佳,特别适合平均负载较低的应用场景。
|
2月前
|
弹性计算 运维 关系型数据库
Serverless高可用架构解决方案评测
Serverless高可用架构方案提供卓越效能与极简运维体验,支持服务托管、弹性伸缩及按量付费,有效降低成本并优化性能。一键部署快速启动,流程直观,文档详实;但在高级配置与特定场景实践方面指导有限。方案采用双可用区部署确保高可用性,自动故障切换保障服务连续。成本模型按需计费,减轻企业负担。功能上集成监控、日志与负载均衡,简化运维,加速上线。性能方面,秒级弹性伸缩保证资源高效匹配负载。总体而言,此方案竞争力强,特别推荐给初创公司及需灵活应对流量波动的场景。
144 2
|
2月前
|
运维 监控 负载均衡
如何构建高可用的系统基础架构
【8月更文挑战第15天】构建高可用的系统基础架构是一个复杂而系统的工程,需要综合考虑设计原则、关键技术和实践策略等多个方面。通过冗余设计、分布式架构、自动化与智能化等技术的运用,可以显著提升系统的可用性和稳定性。同时,加强运维团队的能力建设和制定完善的高可用性策略也是确保系统高可用性的重要保障。希望本文能为读者在构建高可用系统时提供有益的参考和借鉴。
|
2月前
|
关系型数据库 Serverless 分布式数据库
阿里云 Serverless 高可用架构
阿里云的《卓越效能,极简运维,Serverless高可用架构》解决方案提供了全托管服务、自动扩展、高可用性、无缝集成以及内置安全等核心功能。该方案通过免除底层基础设施的管理,允许用户专注于应用程序开发,同时确保应用的稳定运行和资源的有效利用。 **核心功能简介**: - **全托管服务**:用户无需关心底层硬件,由阿里云负责维护和扩展计算资源。 - **自动扩展**:根据业务需求自动调整资源,确保应用在高峰期有足够的计算能力,低谷期则节省成本。 - **高可用性**:多地域和多可用区部署,实现故障自动切换,确保业务连续性。 - **无缝集成**:与阿里云的其他服务(如数据库、消息队列等)深度
下一篇
无影云桌面