促促促,如何确保系统扛得住 | 《尽在双11》抢鲜预览

引言:对技术而言,每一年的双11都是一场严峻的考验,从被流量冲击得溃不成军,被迫奋起抗击,到现在通过技术的力量不断改写双11的用户体验和参与感,阿里的技术伴随着双11成长起来,强壮起来,自信起来。对各位而言,希望大家可以从书中学习更多,掌握更多。
本文选自博文视点与阿里巴巴集团联手推出的重磅新书《尽在双11——阿里巴巴技术演进与超越》,精彩片段抢先试读,不容错过。

  全链路压测被誉为大促备战的“核武器”。如果之前关注过阿里双11相关的技术总结,对全链路压测一定不会陌生,这个词的出场率几乎是100%,从对双11稳定性的价值来看,用“核武器”来形容全链路压测毫不为过。

执笔人

  游骥:阿里巴巴中间件技术部高级技术专家,容量规划、全链路压测、线上管控等稳定性体系负责人;
  隐寒:阿里巴巴中间件技术部高可用架构技术专家,全链路压测负责人。

背景

  历年的双11备战过程中,最大的困难在于评估从用户登录到完成购买的整个链条中,核心页面和交易支付的实际承载能力。自2009年第一次双11以来,每年双11的业务规模增长迅速,零点的峰值流量带给我们的不确定性越来越大。2010年,我们上线了容量规划平台从单个点的维度解决了容量规划的问题,然而在进行单点容量规划的时候,有一个前提条件:下游依赖的服务状态是非常好的。实际情况并非如此,双11 零点到来时,从CDN到接入层、前端应用、后端服务、缓存、存储、中间件整个链路都面临着巨大流量,这时应用的服务状态除了受自身影响,还会受到环境影响,并且影响面会继续传递到上游,哪怕一个环节出现一点误差,误差在上下游经过几层累积后会造成什么影响谁都无法确定。所以除了事先进行容量规划,还需要建立起一套验证机制,来验证我们各个环节的准备都是符合预期的。验证的最佳方法就是让事件提前发生,如果我们的系统能够提前经历几次双11,容量的不确定性问题也就解决了。全链路压测的诞生就解决了容量的确定性问题!

全链路压测1.0从无到有

  提前对双11进行模拟听起来就不简单,毕竟双11的规模和复杂性都是空前的,要将双11提前模拟出来,难度可想而知:

  • 跟双11相关的业务系统有上百个,并且牵涉整条链路上所有的基础设施和中间件,如何确保压测流量能够通畅无阻,没有死角?
  • 压测的数据怎么构造(亿万级的商品和用户),数据模型如何与双11贴近?
  • 全链路压测直接在线上的真实环境进行双11模拟,怎样来保证对线上无影响?
  • 双11是一个上亿用户参与的盛大活动,所带来的巨大流量要怎样制作出来?

2013年8月中旬,当时高可用架构团队的负责人叔同(叔同:高可用架构&运维产品&基础产品团队负责人、资深技术专家。)接下了这个巨大的挑战:打造一套全链路压测平台。平台需要在2013年双11之前上线,错过了这个时间点,我们就必须再等一年。从立项到双11,留给我们的时间只有短短两个多月,时间非常紧,我们需要在这么短的时间里应对一系列历史级的挑战。2013年阿里搬到西溪园区,其他同学都是搬到新工位,全链路压测项目组直接搬到了项目室,进行闭关攻坚。

1 业务改造升级

  2013年核心交易链路就有几十条,牵涉多个BU的几百位研发人员,这些业务链路绝大部分是没法直接压测的,需要进行相应的业务改造和中间件的升级。推动几百号人在短时间之内完成业务的改造在很多公司几乎是不可能完成的,何况还牵涉中间件的升级,中间件的升级一般会有一个相对比较长的周期,有不少业务系统的中间件版本都非常古老(5年前的版本),需要确保无风险直接升级到最新版本。
  在业务端我们需要逐条链路进行一一梳理,从请求进来的系统到请求的最后一个环节(复杂的业务会经过几十个系统。),每一个有阻压测流量往下走的地方都进行特殊的逻辑改造。改造的业务点牵涉100多个,包括登录验证码、安全策略、业务流程校验等。在基础设施和中间件上,我们需要让业务系统的代码尽可能不需要修改,通用的技术通过基础设施和中间件来屏蔽掉,比如压测流量的标识怎样在整个请求的生命周期中一直流转下去,怎样来对非法的请求进行拦截处理。
参与全链路压测改造的技术人员体现了良好的协作精神和执行力,为了同一个目标齐头并进、相互补位,原本认为几乎不可能的事情,最终在一个月内完成了相应的业务改造和中间件升级。

2 数据构造

  数据构造有两个核心点:

  • 双11的买家、卖家、商品数量都非常庞大,需要构造同数量级的业务数据。
  • 需要确保业务数据的模型尽可能贴近双11零点的真实场景,否则全链路压测结果的误差会比较大,参考的价值将会大打折扣。

为此我们专门搭建了全链路压测的数据构造平台,对业务模型进行系统化的管理,同时完成海量业务数据的自动化构造,如下图所示。
        
                      全链路压测的数据构造平台
                      
  数据构造平台以线上数据为基础,借助数据dump(dump:在特定时刻,将储存装置或储存装置之某部分的内容记录在另一储存装置中。)工具进行数据的抽取,并对关键数据进行相应的处理(脱敏、订正等)后进入基础数据池备用。基础数据池是压测数据的超集,具体压测数据的构造基于基础数据集进行数据的再加工。
  除了需要有足够量级的数据,我们要解决的另一个问题是数据的模型应该是怎样的。借助BI工具结合预测算法对数据进行筛选建模,并结合每一年双11的业务玩法进行修订,产出一份最终的业务模型。业务模型的因子牵涉几百个业务指标,包含买家数、买家类型、卖家数、卖家类型、优惠种类、优惠比例、购物车商品数、BC比例、移动PC比例、业务的量级等。

3 数据隔离

  全链路压测要不要做数据隔离、怎样来做数据隔离,在项目立项阶段经过了非常多的讨论甚至争吵。在最开始的时候,我们想做逻辑隔离,直接把测试数据和正常数据写到一起,通过特殊的标识区分开,这个方案很快就被放弃了:线上数据的安全性和完整性不能被破坏。接下来我们提出了另一个方案,在所有写数据的地方做mock(mock:软件开发概念,指模拟),并不真正写进去,这个方案不会对线上产生污染,但评估时还是被放弃了:mock对压测结果的准确性会产生干扰,而我们需要一个最贴近实际行为的压测结果。
  经过反复讨论,最终我们找到了一个既不污染线上,又能保障压测结果准确性的方案:在所有写数据的地方对压测流量进行识别,判断一旦是压测流量的写,就写到隔离的位置,包括存储、缓存、搜索引擎等。

4 流量构造

  双11是一场“剁手党”的狂欢,零点的峰值流量是平时高峰的几百倍,每秒几百万次的请求如何构造同样成为大难题。我们尝试通过浏览器引擎或者一些开源压测工具的方式来模拟用户请求,经过实际测试,要制作出双11规模的用户流量,浏览器引擎和开源压测工具需要准备几十万台服务器的规模,成本是无法接受的,并且在集群控制、请求定制上存在不少限制。既然没有现成的工具可以使用,我们只好选择自己研发一套全链路压测流量平台,如下图所示。
       
                       全链路压测流量平台
                       
  全链路压测的流量平台是一个典型的Master+Slave结构:Master作为压测管控台管理着上千个Slave节点;Slave节点作为压测引擎,负责具体的请求发送。Master作为整个压测平台的大脑,负责整个平台的运转控制、命令发送、数据收集、决策等。Slave节点部署在全球各地的CDN节点上,从而模拟从全球各地过来的用户请求。整套全链路压测的流量平台在压测过程中平稳输出1000多万/秒的用户请求,同时保持过亿的移动端用户长连接。

5 正式上线

  在两个多月的时间里,项目组的成员披星戴月,有一半时间在通宵,另外一半时间是凌晨3点以后下班。2013年10月17日凌晨的1号楼,全链路第一次登台亮相(如下图所示),这一天对整个全链路压测项目组的人都意义非凡,辛苦了两个多月的“大杀招”终于要派上用场了!当压测开始的按钮被按下去,大家都全神贯注地盯着各种系统等着流量上来,1分钟、2分钟过去了,我们的业务系统却丝毫没有流量进来。忙活了一晚上,第一次亮相狼狈收场,当时全场有200多号人,每一次让大家准备好却没有流量发出去的时候,面对着全场200多双眼睛,压测项目组每一个成员的手都是抖的。好在第一次的失败让我们吸取了充分的经验,又经过好几个昼夜的奋战,第二次的压测比第一次进步了很多,到了第三次就已经能完全达到我们的使用预期了。
          
                        全链路压测现场

全链路压测2.0平台升级

  全链路压测诞生之后为系统稳定性带来的改变立竿见影,2013年经过了几次全链路压测,双11零点的表现比以往任何一年都平顺。全链路压测也在阿里一炮而红,越来越多的业务希望能接入进来。

1 平台化

  海量的业务接入给全链路压测平台带来全新的挑战:当时的全链路压测操作都需要压测项目组的成员来进行操控。随着越来越多的业务接入全链路压测平台,压测项目组很快就成了瓶颈,压测平台的能力急需升级。2015年,全链路压测“平台化”项目启动,我们着手将全链路压测朝着平台化的目标推进和实施,做到压测能力开放、业务方自主压测,让更多业务方能够享受到全链路压测的优势和便利,如下图所示。全链路压测平台化项目的上线大幅提升了全链路压测平台的服务能力:2015年大促备战的3个月内,压测平台总共受理近600多个压测需求(比2014年提升20倍),执行压测任务3000多次(比2014年提升30倍)。
        
                        全链路压测平台化

2 日常化

  全链路压测的压测流量和正式流量经过的路径是一致的,如果链路中某一个节点被压挂或者触发限流,势必会影响线上用户的正常访问。为了减少影响,全链路压测一般都安排在凌晨,通宵达旦,非常辛苦!为了减少熬夜,提升压测幸福度,我们启动了白天压测的项目:将线上运行的机器动态隔离出一部分放到隔离环境中,这部分机器上只有压测流量可以访问,白天在隔离环境的机器上进行压测。隔离环境与线上环境几乎一样,从流量入口、中间件、应用后端实现完整隔离。隔离环境完全打通了配置中心、服务注册中心、消息中心、地址服务器等基础设施,不需要业务系统做任何改造即可完成。并且是直接从线上机器按照特定规则选择到隔离环境中,机型配置跟线上基本一致,使用完毕之后直接恢复到线上集群中,不会影响线上集群的容量。大促备战期间,我们可以白天在隔离环境中进行小目标、小范围的全链路压测,用极小的代价提前发现问题。由于隔离环境场景相对于其他线下环境更加真实、操作快捷、不占用额外机器资源,在预案演练、破坏性测试、线上问题排查、故障演练等其他场合也获得了比较广泛的应用。

全链路压测3.0生态建设

  2016年在三地五单元混合云部署架构下,电商一半以上的资源部署在云上。在庞大的电商系统背景下,如何能够在最短的时间内完成一个单元的搭建和容量准备成为摆在我们面前的一道难题,而全靠“经验之谈”和人工介入是不可能完成的任务。2016年初,“大促容量弹性交付产品”立项,旨在减少甚至释放活动场景的容量交付中的人工投入,并将大促容量交付的运维能力沉淀到系统中,使全链路容量具备“自动化”调整的能力。我们提出了大促自动化备战的想法,将大促容量准备的各个环节进行系统层面的打通,从业务因子埋点、监控体系、模型预测、压测数据构造、压测流量发送、压测结果分析、压测报表进行自动化串联,大幅缩减了在大促容量准备阶段的人员投入和时间周期。围绕全链路压测的核心基础设施,全链路压测的周边生态逐步建立起来,打通建站、容量、监控等配套技术体系,如下图所示。
        
                        全链路压测3.0生态
                        
  全链路压测在保障系统稳定性的同时,也为业务稳定性的保障提供了强有力的支持,2016年我们落地了全链路功能测试、大促功能预演等一系列项目:创造性地在隔离环境提前将系统时间设置到双11的零点。通过在这个提前的双11环境购买一遍双11的商品,进行充分的业务验证,最大限度地降低双11当天的业务问题。

总结

  每年双11前夕,全链路压测都要组织好几次,不断地通过压测发现问题进行迭代优化,全方位验证业务的稳定性,我们的业务系统也只有在经过了全链路压测的验证之后才有信心迎接双11零点的到来。全链路压测将大促稳定性保障提升到新的高度,是双11、双12等大促备战最重要的“核武器”,并且随着业务的发展不断进化,持续发挥着不可替代的作用。
  



        

                      阿里巴巴集团官方出品
                    独家奉献双11八年技术演进与创新
                涉及架构/稳定性/商业拓展/移动/生态促进等内容
  “双 11”,诞生于杭州,成长于阿里,风行于互联网,成就于新经济,贡献于全世界。
  从 2009 年淘宝商城起,双 11 已历经八年。每年的双 11 既是当年的结束,又是走向未来的起点。技术的突破创新,商业模式的更替交互,推动着双 11 迈步向前。
  本书是迄今唯一由阿里巴巴集团官方出品、全面阐述双 11 八年以来在技术和商业上演进和创新历程的书籍。内容涵盖在双 11 背景下阿里技术架构八年来的演进,如何确保稳定性这条双 11 生命线的安全和可靠,技术和商业交织发展的历程,无线和互动的持续创新与突破,以及对商家的赋能和生态的促进与繁荣。
  本文选自博文视点与阿里巴巴集团联手推出的重磅新书《尽在双11——阿里巴巴技术演进与超越》,点此链接可在博文视点官网查看此书。
                     
  想及时获得更多精彩文章,可在微信中搜索“博文视点”或者扫描下方二维码并关注。
                       

时间: 2024-11-05 11:45:55

促促促,如何确保系统扛得住 | 《尽在双11》抢鲜预览的相关文章

如果我来负责支付宝双11大促保障(四)

在梳理好有哪些系统将参与到大促后,我们的目标就是对它们的现状进行健康检查,为后续制订优化方案提供数据支持. 同样,检查纬度还是依照上面罗列的,从自身.依赖方.服务方.基础服务和后台服务五个纬度来检查.   自身 1.硬件主要是检查服务器的各项指标,包括CPU.IO.内存.连接数以及磁盘剩余空间. 2.软件此次我们只是着重于检查JVM的一些参数,如GC策略和启动参数. 3.接口服务 接口性能.检查tps.成功率.耗时.流控阀值以及超时时间(调外部服务). 定时任务.要明确其作用,用来决定是否执行关

如果我来负责支付宝双11大促保障(五)

接下来我们需要梳理的是核心路径容量模型.首先,需要梳理的是核心路径调用链,就是指核心路径上的调用接口.其次,梳理各接口之间的调用信息,包括调用顺序.调用次数以及同级别接口调用流量比.这些信息都是为了后面建立容量模型做准备.   制订子目标 预估总流量,制订目标TPS在收集完上面的信息后,我们需要分解目标,依次完成各个子目标.在第一步,我们收集了大促活动的详细信息,因此,我们根据这些数据和历史数据预估此次活动的量,然后乘以一定的系数,作为我们此次的目标TPS.比如,双11活动,我们预估将有600T

如果我来负责支付宝双11大促保障(一)

双11火爆的气氛还没消去,全民狂欢的情景还历历在目,看到阿里炫出的成绩单,突然一阵,如果我是支付宝双11大促保障的负责人,我该怎么保证每一位顾客能越快越满意的买到自己心爱的商品呢?接下来,我将详细介绍一下我的实现步骤. 对于这么重要的活动,心中自然要有个明确的计划.主要分为十二个大的步骤.(1)明确目标(2)梳理外部影响条件(3)梳理内部现状(4)制订子目标(5)识别瓶颈点(6)性能优化(7)梳理风险点(8)制订应急预案(9)梳理非关键成员对关键成员的影响(如资源竞争)(10)制订沟通机制(11

双11大促期间,作为一个测试人员的反思

双11大促,发现大部分测试人员只能做做功能测试. 但其实我们能做的很多,但是都是要求有一定权威性和执行力,我们所缺乏:1.针对免测情况的各业务风险评估--mike:目前的EOS权限控制在开发,RPM根本没有权限控制系统,所以测试环境部署确实,业务免测测试也经常不知道.这个问题已经在沟通解决了,会让运维开发RPM的权限管理系统,慢慢地把权限从开发人员收回,免测试发布一定要经过测试人员(部署测试环境这一环节,部署的时候由对应测试人员评估风险) --me:其实这个也不解决根本问题,就算把权限从开发收回

MySQL提升课程 全面讲解MySQL架构设计 打造扛得住的MySQL数据库架构

第1章 实例和故事决定电商11大促成败的各个关键因素.1-1 什么决定了电商双11大促的成败1-2 在双11大促中的数据库服务器1-3 在大促中什么影响了数据库性能1-4 大表带来的问题1-5 大事务带来的问题 第2章 什么影响了MySQL性能详细介绍影响性能各个因素,包括硬件.操作系统等等.2-1 影响性能的几个方面2-2 CPU资源和可用内存大小2-3 磁盘的配置和选择2-4 使用RAID增加传统机器硬盘的性能2-5 使用固态存储SSD或PCIe卡2-6 使用网络存储SAN和NAS2-7 总

支付网关 | 京东618、双11用户支付的核心承载系统(上篇)

二零一七年六月二十一日,就是年中大促刚结束的那一天,我午饭时间独在办公室里徘徊,遇见X君,前来问我道,"可曾为这次大促写了一点什么没有?"我说"没有".他就正告我,"还是写一点罢:小伙伴们很想了解支撑起这么大的用户支付流量所采用的技术." 「摘要」由于设计时我跟小伙伴们把系统的定位更偏向于具有用户支付事务处理能力的消息总线.业务深度耦合涉及比较广,感觉一次性到位说清楚不太可能.故本篇分为上下两篇,上篇仅对支付网关架构和支付业务流程进行基本介绍,采

h5 实现调用系统拍照或者选择照片并预览

这次又来分享个好东西! 调用手机相机拍照或者是调用手机相册选择照片,这个功能在 手机端页面 或者 webApp 应该是常用到的,就拿个人或会员资料录入那块来说就已经是经常会碰到的, 每当看到这块功能的时候,前端的小伙伴就得去找各种各样的插件.除非你收藏了什么好东西,或者是你收藏了什么比较旧的.需求跟不上的好东西,需求不一样体验不好 那你提交了,产品经理会买你账吗? 好了,咱入正题! 这里主要是针对手机端页面或者webApp的,pc端页面效果欠佳(有时候点击选择按钮,弹框要等你上完厕所才能弹得出来

Win10预览版系统下载:中文简体64位ISO下载

安装 Windows Technical Preview 前,请务必查看系统要求和其他重要信息. 如果你已经准备就绪,请按照下面的步骤下载一个名为 ISO 的特别文件,你可以使用该文件安装该预览版: 单击此页面上的"下载"链接之一. 下载完成后,将该 ISO 文件传输至 DVD 或 USB 闪存驱动器等安装介质. 双击安装介质上的 setup.exe 并按照步骤进行操作."开始"菜单重要提示将 ISO 文件转换为 DVD 的最简单方法是,使用 Windows 磁盘映

Windows、Linux、ARM、Android、iOS全平台支持的RTMP推流组件EasyRTMP- iOS接入后,进入预览界面系统直接崩溃的原因分析

在接入EasyRTMP-iOS时,进入预览界面直接崩溃,是什么原因? 分析问题: iOS系统对于权限控制的很严格,因为预览需要用到相机权限.麦克风权限等,都需要向用户申请这些权限. 解决问题: 在Info.plist文件中,添加如下权限申明,并描述清楚您的用途: <key>NSCameraUsageDescription</key> <string>此App会在推送视频流时访问您的相机权限</string> <key>NSMicrophoneUs