八年双11,交易额增长 200 倍,交易峰值增长 400 多倍,阿里技术经历了什么?

开发 架构
阿里巴巴中间件技术部的高级技术专家周洋(中亭)从能力大促、精细大促和效率大促三个方面探寻双 11 高可用架构演进之路,并对未来双 11 的挑战进行了展望。

[[200009]]

阿里巴巴中间件技术部的高级技术专家周洋(中亭)从能力大促、精细大促和效率大促三个方面探寻双 11 高可用架构演进之路,并对未来双 11 的挑战进行了展望。

[[200010]]

阿里双 11 的技术挑战

双 11 技术挑战的本质是使用有限的成本去实现***化的用户体验和集群整体吞吐能力,用最合理的代价解决零点峰值,支撑好业务的狂欢。

阿里做双11已经有八年之久了,八年来双11的交易额增长 200 倍,交易峰值增长 400 多倍,系统复杂度和大促支撑难度以指数级攀升。

并且经过多年的发展,双 11 技术实现链条中的变量不断增加,如峰值的增量和系统架构的变化、交易峰值的组成、拆单比、每个业务入口的访问量等,这些变量也给系统带来了不确定性。

回顾这八年的双 11 零点之战,它推动了阿里的技术进步、推动了架构优化,加速了技术演进和沉淀。

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

阿里双 11 高可用架构演进

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

能力大促***个要求是解决扩展性的问题。上图是淘宝 3.0 分布式架构,其意义在于让淘宝从一个集中化应用转变为分布化应用。

在该架构中对业务进行了分层,同时在系统中***使用中间件、分布式调用、分布式消息、分布式数据库;架构底层沉淀了分布式存储和缓存。

目前而言,大部分互联网应用都是基于这一架构的,并且发展到现在,该架构并无太大的变化。

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

  • 系统的可用性和故障恢复能力,以前集中化架构,出现问题回滚即可;现在由于涉及到众多分布式系统,快速排查和定位问题变得十分困难。
  • 分布式改造之后,单个系统存放在特定机房里,随着业务发展,机器数目的增加,机房应用层水平伸缩瓶颈、数据库链接等都成了挑战。
  • IDC 资源限制,单个城市已经不足以支撑业务的增长规模。
  • 容灾问题,单地域 IDC 单点、网络、台风、电力等导致高风险。
  • 国际化部署需求,可扩展性再次成为瓶颈。

针对上述挑战,我们采用了异地多活方案,具体从四个方面出发:首先建设异地单元机房,其次由于业务中买家维度数据远多于卖家维度数据,且卖家维度数据变化并非十分频繁,因此可以将流量按用户维度进行切分。

此外,由于走向异地***的挑战是网络,为了减少异地调用的延时,必须实现业务在本单元的封闭性,减少远程调用,***,由于容灾的需求,数据层实时同步,保持最终一致。

异地多活架构

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

卖家的数据部署在中心,单元的数据会同步到中心,中心卖家的数据也会同步到各个单元,但在各个单元内只能对卖家的数据进行读操作。

那么异地多活的到底有什么意义呢?首先异地多活消除了 IDC 资源单点和容量瓶颈,其次解决了异地容灾问题,业务可以秒级快速切换。

此外,异地多活简化了容量规划,提升了伸缩性和可维护性。***,通过异地多活解决了可扩展性问题,为后续架构演进打下坚实基础。

能力大促——容量规划

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

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

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

压测方案

为了应对上述挑战,我们需要从全链条的角度出发进行压测和容量规划。全链路压测是在线上集群模拟真实业务流量的读写压测,完成从网络、IDC、集群、应用、缓存、DB 以及业务系统上下游依赖链条的容量、性能压力测试。

整体压测通过自定义压测工具,大流量来自机房外部,进而构造线上测试数据,且业务模型接近真实;全链路压测隔离了测试数据和正常数据,两者之间互不影响,并且全链路压测时是对用户体验无感知、无影响的。

全链路压测通过复用中间件的能力,具有超大规模的集群压测能力,每秒千万 QPS。同时将压测引擎部署到全球各地的 CDN 上,实现了分布式部署压测引擎,按照约定的时间发送压测数据。

其次,压测数据是基于线上真实数据进行了脱敏和偏移,数据模型与双 11 极其接近。此外,实现了线程级隔离,无脏数据,压力测试直接作用于线上集群,暴露问题更加精准。

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

能力大促——限流降级

限流降级是能力大促的必要要求。在双 11 开始前,尽管我们准备了大量的机器和能力,然而在双 11 零点到来时,真实业务量还是有可能大于我们的预期。

此时,为了确保我们的机器不超负荷运作,我们采用了限流措施,超过机器极限的业务全部拒绝,避免系统因业务流量的突然过大而崩溃。

目前,阿里能够做到从线程数、请求值、负载多个角度进行限流,从而保障系统的稳定。

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

精细大促——依赖治理

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

精细大促——开关预案

精细化双 11 控制的首要机制是开关预案。开关是让系统切换不同功能表现的标准技术,可以无需变更代码只推送配置控制系统行为,让系统的后门标准化。

开关中心配置变更可以实时下发到集群,且操作行为对业务而言是原子性的。开关预案整合了一批业务开关、限流等操作,将多系统的后台操作组装批量执行;实现了预案推送是有顺序性的,保证业务切换的一致性和完整性。

精细大促——故障演练

统计学的数据显示:当服务规模大于一定数量时,硬件故障无法避免。因此,系统要面向失败做设计,测试系统健壮性的***方法,就是不要用正常方式使服务停机。对应线上系统,要实现容灾,首先需要实现背后工具体系的容灾。

由于线上故障是一种常态,系统负责人要具备快速发现和处理故障的能力,需要实战机会来成长。另外,跨团队的流程也是需要加以重视,由于业务分布式的特性,出现故障时需要业务系统的上下游共同协作,这就对流程提出来严格的要求。

故障演练的实现方案

前期,我们将阿里电商常见的故障进行画像和分析,得到初步结论,按照 IaaS、PaaS、SaaS 层进行初步划分,但这个模型无法完全通用,并非包含所有的故障。

因此,后期我们对这一模型又进一步抽象,将故障分为进程内的故障,如代码死循环等;进程外的故障,如磁盘读写速度变慢、网络波动等;分布式调用依赖的底层设施故障,如数据库、缓存或者其他设施出现故障。

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

从去年双 11 开始,阿里开始使用线上统一演练环境,通过逻辑隔离,动态扩展逻辑环境,按需租赁,简化测试步骤,使得演练结果更加真实。

同时多套环境互不影响,严格保证环境的稳定和安全;支持用户、业务、数据、流量特征的分流和隔离,提高了效率,赋能业务创新。

效率大促——流量调度

在线上集群中,如果个别机器发生故障,为了保证业务的整体稳定性,需要对故障点进行流量调度。

流量调度通过实时探测与监控分布式环境中每一台机器的状况,如果机器发生故障,则使用分布式服务具有的自我隔离和自我修复能力,使用流量调度和负载均衡机制,通过关注局部用户请求和用户体验,提升整体可用性。

阿里双 11 未来挑战

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

实现更加精细化、数据化、智能化的双 11。

从容量确定性到资源确定性,从每个实例部署在哪里***、精确到每个内核如何分配***。

更加精准的分析、预测流量模型和业务模型,实现预测、引导相结合,逼近真实、增加确定性。

实现技术变量的采集、分析、预测,数据分析驱动,自主决策处理,关键技术指标的预估错误系统做到自适应,弹性处理。

在体验、成本和***吞吐能力方面找到新的平衡点。

 

责任编辑:武晓燕 来源: 阿里中间件团队博客
相关推荐

2019-07-17 08:58:17

架构业务云化

2013-11-11 09:44:45

阿里双11交易

2018-07-26 21:22:00

云测试

2017-02-20 20:04:05

系统超轻量日志实现

2018-04-23 11:34:43

阿里巴巴监控系统人工智能

2011-11-08 16:12:28

淘宝服务

2012-11-19 14:40:52

Square

2017-11-28 10:23:24

阿里双11

2012-03-05 20:06:42

iPad

2015-11-11 21:46:45

阿里巴巴双11

2011-06-24 15:36:29

PayPal移动支付Square

2015-11-13 10:53:58

京东双十一

2019-11-14 18:38:31

阿里云双11天猫

2017-04-19 09:40:55

双11阿里巴巴

2018-11-12 11:47:49

2021-10-15 14:06:47

比特币加密货币货币

2017-05-16 15:39:28

互联网

2015-11-12 17:37:35

魅族

2019-11-12 09:28:10

区块链技术应用程序

2022-03-07 18:45:29

腾讯云数据库TDSQL
点赞
收藏

51CTO技术栈公众号