老庙黄金2016春晚抢红包活动技术架构详解

  • 时间:
  • 浏览:1
  • 来源:彩神快乐8_神彩快乐8官方

通过调整nginx及linux内核参数,使得单机并发从几百提升至2100;

知道了并发峰值,才好来评估强度、负载均衡、服务器数量等。这么为啥来预估峰值?一般根据活动预计参与的人数和参与八时 可不还能不能来做简单估算。类似预计会有 100万人参加,共一另1个小时,这么平均每秒并发只是我 2100左右,机会一般在活动现在刚开始时压力会比较大,系统最大峰值一般是平均值的5-10倍左右。当然具体的要看活动形式来估算。在本次春晚活动预估的每秒并发为6万左右。

大致流程如下:用户点击支付宝咻一咻,会随机老出老庙红包界面,咋样让点击打开红包则由服务端随机返回一另1个不同额度的优惠券,咋样让用户通过优惠券id进行实体店机会网店的消费。效果图如下:

时效性非常强, 活动一般都是固定的时间机会事件触发,错过了就这么了;

网络架构层面,阿里云的强度是BGP的,咋样让网络质量基本不需要担心。咋样让强度可不还能不能从 1Mbps 至100Mbps随时调整,咋样让可不还能不能通过增加多个SLB的妙招来进一步提高整体强度。同時 机会红包页面是静态的,为了进一步提升用户体验,减轻系统压力,使用CDN进行缓存,CDN可不还能不能有效降低延迟,减小系统源站压力。

5. 自动化部署

网络层:DDoS防护、域名解析、CDN加速;

在今年的春晚红包活动中,机会并发压力较大,同時 业务需求不冗杂,咋样让交互基本都放上去客户端来完成。

数据层,机会红包涉及到后续消费时的验证,咋样让每个红包可不还能不能有唯一id。这么生成id和存放数据机会用关系型数据库在压力大时很容易把数据库撑爆,那就要考虑到用缓存来外理,咋样让最后确定OCS(memcached)作为数据层。而数据的持久化则通过异步外理妙招写入关系型数据库RDS(MySQL)(还有一另1个确定是Redis,具体就不再累述)。

为啥当当只是们会强调弹性?机会业务弹性太满,他说远远不及预期的访问,咋样让都是机会远远超过预期。在网络层,当当只是们确定按量付费,咋样让峰值就可不还能不能自动调整了。应用层的弹性,通过SLB后增加机器实现,同時 为了应对突发情况汇报,可不还能不能使用ESS来自动扩展,咋样让本例中未用。OCS也是可不还能不能在线升级,只可不还能不能点下界面1分钟即可完成升级,而传统服务器机会要扩容,不停机是没能的,咋样让也没这么快。当然,弹性在秒杀类系统中作为防御性妙招,而压力测试就可不还能不能做充分。

活动形式的设计会直接影响到系统的下发,类似是在客户端完成一系列交互后发送一次请求至服务端,还是每次交互都是连接服务端。交互都是客户端完成实现比较简单,对服务端压力也最小,咋样让交互形式比较固定。

1. 7*24 监控

本例中使用了多个PTS压测集群,最大并发6万。在一现在刚开始的测试中发现,单机施压机器合适100左右并发,6万TPS共才可不还能不能100台ECS。通过系统参数调优、OCS升级,增加SLB数量至五个,QPS总体提升至6万。压测目的基本达到,而从压测准备到测试完成整个只可不还能不能 1天半即完成。传统IT妙招一半个月时间机会压测环境还没准备好。

3. 参数调优化

抢红包系统的逻辑一般都比较简单,用户在一另1个页面上点击,添加简单的交互,将请求发送至服务端,由服务端接受请求并根据业务需求外理后返回红包结果给客户端。这么在需求调研阶段就可不还能不能才能 解清楚几个信息:

监控是做好系统运维的第一步:一般来说可不还能不能监控 服务端口,URL,业务逻辑;

正确的架构是系统成功的基石,这么当当只是们就要从业务层面来分析下抢红包活动的系统架构有什么典型特点?

抢红包、秒杀等营销手段现在这么流行了,而你类似活动却带给IT攻城狮们巨大的挑战。抢红包系统只是我端看起来都是很简单的,但实际上对应的后端系统却非常冗杂,机会瞬时高并发所带来的问题报告 将整个系统架构的冗杂度提升了几个数量级。

四、运维护航

稳定性要求高,只许成功不许失败。正是机会活动的时效性很强,比如春晚直播的那一两分钟,机会系统老出哪怕10秒的故障对整个活动的效果就会大打折扣; 

云监控可不还能不能提供云资源层面的监控。而应用层、业务逻辑等监控可不还能不能使用Zabbix来进行全面的监控。

整个系统确定阿里云作为基础架构。这么为啥用云而都是传统的硬件机会虚拟化IT架构来实现呢?并都是机会现在云计算流行而选云,只是我机会可不还能不能才能 云计算才能胜任,为啥?

无法做全面的冗余,机会故障有机会在网络,有机会在io,都是机会在数据库,缓存等。机会什么愿因只靠冗余是无法保证系统100%的稳定的,这么限流手段就可不还能不能要使用了,所谓限流只是我当系统访问流量压力超出系统所能承受时应该作何响应,给用户返回排队页面机会让客户稍后重试,你类似应答对后台系统基本无压力,同時 可不还能不能将并发错峰。嘴笨 有点痛 “无赖”,但这是此类系统必不可少的故障应对机制。

1. 基础设施架构选型

大部分活动在进行中机会现在刚开始后都可不还能不能统计活动情况汇报信息,类似每个八时 的用户数、访问量、业务量等等。咋样让在系统设计时就可不还能不能考虑到整个系统的访问情况汇报和用户行为数据以何种形式和妙招保存下来。数据库、日志、缓存等手段都是常用的,咋样让在在高并发情况汇报下,日志对性能的影响也都非常大。以写日志文件为例,单机数千并发频繁的磁盘IO会愿因严重的响应问题报告 ,只是我类似系统都占据 过看起来太满起眼的日志文件是性能瓶颈的罪魁祸首。

最终整个系统的架构如下:

资源弹性,计算资源、网络资源可不还能不能几个随时就可不还能不能获取和扩展。 

为进一步的数据分析准备。SLS的数据可不还能不能直接转移到 ODPS,咋样让后端当当只是们用ODPS进行数据分析,我只可不还能不能把数据丢进去计算就可不还能不能才能 。

4. 网络架构解读

1. 并发峰值的估算

告诉我该冗余几个。机会访问量与否会超过预期是告诉我的;

应用层:将虚拟机ECS分为另1个可用区A和B来提高系统整体可用性。OCS用于做数据缓存,MQS则通过消息队列妙招将你类似数据异步写入数据库。而所有服务器的日志都集中记录入SLS,为后续的数据分析做好准备,同時 也方便日志的查找;

4. 上线及缓存预热

恐怖的峰值并发,并发/TPS/QPS一般都是在数万甚至数十万。(双11天猫的交易合适在6万笔/秒);

快速交付能力,整个项目从开发到上线可不还能不能才能 20天时间,不需要云估计没能完成。 

高可用是保证系统稳定和健壮性的必要手段。从整个系统架构来审视高可用,在CDN层面一般都没问题报告 ,即便是有问题报告 也会回源,只是我这里不需要考虑。 SLB的高可用,阿里云SLB有一种机会是集群机制提供了容错,同時 选了五个SLB也会提高可用性。在虚拟机层面,要外理机器都是同一另1个可用区(机房),机会一半的机器可放上去可用区A,另一半放上去可用区B。缓存和数据库层面,阿里云OCS、RDS有一种就提供master-slave的高可用机制,咋样让直接拿来用即可。通过什么当当只是们才能看出来阿里云产品基本都自富富含可用属性,这在当当只是们构建系统架构八时 省了絮状的成本和精力。



接入层使用负载均衡SLB的愿因很简单,机会整个系统的并发会很大,都是几台机器可不还能不能完成的,咋样让可不还能不能用SLB将整个负载分担至 几十台机器上,同時 都是另1个好处: 1. 可用性大幅提升,单个机器机会某一另1个可用区(机房)故障不需要影响系统 2. 计算的扩展性,访问量大只可不还能不能在SLB后增加机器即可。并发量大时接入层很容易成为瓶颈,咋样让使用SLB的好处是它有一种只是我一另1个集群,咋样让在负载转发上做好了高可用和优化,咋样让当当只是们只可不还能不能简单的配置SLB的端口转发规则即可,你类似的基本可不还能不能 考虑。

成本,机会整个活动只持续春节期间1半个月左右的时间,较低的综合成本是可不还能不能考虑的。 

3.雪崩效应和限流外理妙招

2. 活动参与形式及交互形式

抢购类系统最容易被恶意攻击,无论是渗透还是DDoS攻击,都是对系统和营销活动造成很恶劣的影响。此次活动当当只是们采用阿里云高防IP来应对DDoS、cc攻击,同時 http采用https来提升安全性。你类似基本的安全扫描才可不还能不能通过云盾来完成,还是非常方便的。



上线前最重要的只是我压力测试,机会预计并发在6万TPS以上,只是我当当只是们确定阿里云PTS做压测。PTS的最大好处只是我即开即用,可不还能不能几个压力源也只可不还能不能输入参数即可,不需要再去考虑去用Loadrunner类似的软件去搭建压测环境。机会本次抢红包逻辑比较简单,咋样让压测只可不还能不能压测抢红包的url即可。 

TCP Conn,tcp_syncookies;

7. 安全架构有点痛 要

8.大数据架构是利器

日志统一管理查询,便于后续问题报告 排查和分析;

为啥要考虑大数据?机会在传统IT模式下,基本不需要纪录每一另1个请求的日志,机会什么仅仅用于排错,后续只是我会进行分析,日志满了就删掉。传统IT架构数据挖掘的成本太高,产生价值太低,只是我当当只是会们把日志丢弃了。这么在本项目中当当只是们把每一另1个用户的请求都记录下来,传统妙招当当只是们会把日志纪录到磁盘中,咋样让秒杀时每个机器都承担成千上万的并发,反应到IO只是我有只是我磁盘IO,普通磁盘肯定会失去系统性能。

3. 活动数据需求

事后也证明保存日志是多么重要,客户他说一现在刚开始可不还能不能 ,但只是看得人活动效果,又只是,就可不还能不能很方便的完成统计。基本上所有什么因素都是在一另1个完善的架构中所可不还能不能考虑,这么当当只是们的下发就基本完成了。

咋样让日志纪录上当当只是们确定SLS,有另1个好处:

当当只是会们知道CDN在第一次访问可不还能不能回源的,第一次事先的访问才会走cdn,秒杀数年会有絮状请求瞬间同時 到CDN,你类似事先CDN还这么缓存,愿因着大部分压力都是回到源系统,很有机会直接把系统搞垮。为啥应对,很简单,进行预热。 预热也很简单,用阿里测机会17ce等在线测试平台多测几个,只是我全国各地的CDN几点都进行了缓存,当业务开启正式客户进来时直接就可不还能不能从cdn返回。

首先http页面要尽机会小,节省网络强度,提升并发。当然你类似抢购必然要用移动设备,咋样让移动设备的适配都是点痛 要,H5才能带来很大的便利性。同時 页面交互尽机会在本地完成,只是我用户会不停的点击,交互要尽机会少的和服务端通信,咋样让只传输必要信息,比如本项目中的概率数字、唯一id等信息。

1. 整个系统的代码逻辑太满冗杂,咋样让为了应对并发可不还能不能全面的考虑;

2. 性能压力测试;

采用典型的三层架构,接入层—负载均衡SLB,应用层—虚拟机ECS,数据层-数据库RDS。

数据层:机会单个RDS的性能有限,咋样让使用DRDS来组成一另1个RDS MySQL集群,将系统压力分担至多个RDS;  

5. 高可用的必要手段

应用层,使用python开发,pypy+tornado+Nginx作为后端服务。机会后端逻辑简单,同時 为了追求开发强度而确定python,而使用Pypy比原生的CPython强度要提升10倍以上,Tornado的非阻塞异步IO外理妙招才可不还能不能轻松应对高并发,Nginx作为静态页面的外理也是非常合适的。

二、 下发

在本例中,当后台相应不及时机会压力过大时,会返回给客户一另1个请稍后再试的提示。

限流通过Nginx参数 limit_req 的burst。

性能要求高,可不还能不能 慢。高并发时往往带来的只是我对请求的响应时间变长,咋样让在促销情况汇报下过长的延时用户是无法忍受的;

说到这里,当当只是们机会以为架构机会差太满了,咋样让还少了另1个有点痛 要的:安全和大数据外理。

运维监控:云监控和Zabbix结合来实现整个系统从云资源到应用到业务的监控。Ansible用于自动化部署;

抢红包、秒杀系统最怕的是雪崩效应,机会访问量的不可预知性。所谓雪崩效应是指单个设备的故障而引起的系统全面瘫痪。 比如只是我有20台机器,其中2台坏了理论上是这么关系,咋样让机会访问量被分配到你类似18个机器上,愿因这18台的压力经常 增加,从而引起更多机器的崩溃,而像雪崩一样,一另1个地方一另1个地方沦陷,最终整个系统挂了。 应对雪崩,冗余的资源是可不还能不能要考虑的,咋样让有局限性,机会:

6. 弹性扩展要针对峰值自动调整

基于什么因素考虑,当当只是们来分别分析下具体架构:

运维方面,最主要就做应急方案了。网络瓶颈咋样外理,通过按量付费的妙招可不还能不能对强度不做上限限制。快速部署,通过镜像+api的妙招,可不还能不能瞬间增加几十台机器。

系统压力未知性,访问量,用户量,并发量的不可预测。在活动前一般都是做一定的预测,咋样让不确定性非常大,机会机会某一另1个特殊事件,系统访问量就会远远超于预期。咋样让健壮的架构可不还能不能才能承担超额的访问量,咋样让要做到足够弹性,当业务压力增长时可不还能不能随时扩容。

在系统运行或项目过程中,难免会遇到需求变更可不还能不能去修改代码并部署的,使用ansible来对几十台及其进行快速部署。

2. 应急方案

几十台机器的并发日志写入性能没问题报告 ;

2. 应用下发

ODPS则用来做最终的数据分析,比如用户量、访问量、用户行为等;

接入层:主只是我4层负载均衡SLB,将访问请求下发至后端服务器;

三. 开发测试

最后再强调一下,整个系统从需求调研到开发,再到压力测试和上线只用了2周时间,在春晚活动中,整个系统表现非常稳定,很顺利的扛过了峰值压力。而在成本方面,只是我一另1个系统使用传统IT妙招软硬件投入100万是合适的,而云的按需付费模式在此项目中成本只可不还能不能1/10还可不还能不能 。你类似时间紧、任务急、很冗杂的项目在传统IT模式下几乎是mission impossible,这也正是云计算所带给当当只是们的力量。

了解了什么典型特点,下发就要正式现在刚开始了。

笔者所在的驻云科技就参与了春晚支付宝老庙黄金新春抢红包活动系统的建设和护航工作。在这里跟当当只是们做个分享,同時 探讨咋样利用云计算技术来在短时间内构建强大且具备灵活扩展性的架构。



具体来解读下:

一、 架构需求调研