《进化——我们在互联网上奋斗的故事》一一1.5 电商大促盛宴背后的技术-阿里云开发者社区

开发者社区> 数据库> 正文
登录阅读全文

《进化——我们在互联网上奋斗的故事》一一1.5 电商大促盛宴背后的技术

简介:

本节书摘来自异步社区出版社《进化——我们在互联网上奋斗的故事》一书中的第1章,第1.5节,作者:北大首届互联网CIO-CTO班全体同学,更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.5 电商大促盛宴背后的技术

进化——我们在互联网上奋斗的故事
随着近年来互联网的越发普及,电子商务已经成为越来越多人生活的一部分,并有成为购物首选的趋势。非常有幸从2010年起,我就加入了1号店这个电子商务的前沿企业,作为一个技术人亲身经历了公司规模和系统规模从小到大、快速发展的这几年。其中印象最深刻也最有代表性的就是一次又一次的大促,每一次公司生意规模的增长背后都伴随着技术层面的不断升级和演进。

1号店有一种长达一个月的促销叫“周年庆”

说起电商的大促大家应该都经历过的,各大平台每年你方唱罢我登场,各类促销不断,就仿佛菜市场里面挥泪大甩卖的吆喝似的。其中不乏各种超值商品,特价秒杀,搏了大家的眼球,也确实让很多真正的消费者获得了优惠。一般活动也就是一天或几天,而1号店有一种长达一个月的促销叫“周年庆”。

整个7月,全公司都处在一个紧张而又兴奋的节奏里,各种促销活动从促销页面制作,到促销商品选择,到商品入库,再到仓库发货,快递配送,整个电子商务全局供应链都在紧张中忙碌,为了给顾客带来更好的体验,为公司的业务增长能够站上一个新台阶而不停地高速运转。其中系统的稳定是重中之重,没有整个系统的稳定,任何一个环节出现问题都会直接影响公司业务。

为了准备2011年的周年庆,提前半年就开始立项,我们做了一件大事就是拆库,把之前唯一的核心数据库一分为五,根据数据使用场景和压力进行分库。非常庆幸我们在周年庆之前完成了数据库的拆分,支撑了业务的需要,从当时压力的情况来看,如果没有这次数据库拆分,是肯定无法支撑周年庆的订单量的。这对系统而言也是一次质的飞跃。

其中印象最深的是2012年的周年庆,欧洲杯决赛的那个凌晨,相信很多兄弟都会熬夜去看西班牙对意大利的决赛,而那晚我和一众负责前台页面展示的兄弟们一起鏖战了四十多个小时。为了给用户更多更好的购物体验,在大促当天上线的主页面上做了几百个展示橱窗加整点秒杀,而当时的系统以往最多的时候也就是使用过几十个促销栏位,于是便出现了部分浏览器打开速度缓慢的问题。为了解决这个问题,我们的业务同事非常努力。问题解决后我们引入了促销页面测试准入流程,以后的大促所有页面必须提前测试,技术确认后再上线,从那以后这样的事情就没有再发生过。从软件角度上说,这也许不是最强大的软件方式,但从互联网电子商务快速发展的角度来说,技术了解业务、技术与业务相结合,开发出合适的能够快速响应变化的产品是经济合理的方案。

有一个日子叫12·21

天猫的“双11”、京东的“6·18”,相信这两个日子是大家最耳熟能详的了,而1号店也有个自己打造的日子叫“12·21”。

那是2010年的时候,随着1号店整体规模和整个电子商务行业的快速发展,单靠最开始起家的自营模式无法满足顾客的需要和在业界的竞争中获胜。1号店的商城模式“1号商城”快速发展,从入驻第一个月的几十家到目前的上万家。2011年的双11过后,我们的业务同事提出了要做“12·21”这个1号店商城大促节日的想法,主打全场五折,公司管理层很快就决定了支持这个想法,建立一个自己的节日。

这对系统的挑战是非常大的,需要我们在短短一个月时间,把系统承载能力提升几十倍。当时我们的CTO亲自挂帅,带领所有技术团队的负责人组成项目专项组,在当时硬件资源没有增加的情况下,确定了数据库历史数据迁移、缓存服务器调整、核心程序代码优化、性能测试保障、临时找供应商借部分硬件等一系列具体方案。我在这个项目中是项目问题跟进总负责人,在这个项目中我们创新性地提出了对每个事项都要有负责人和监督人,如果该事项没有完成到位,我们首先问责监督人,以此保证各项工作的按时完成,这样的方式我们一直沿用到之后所有的重要大促准备。当时最困难的点还是在于核心程序的优化,那时候我们整个系统Service化还没有做好,系统的水平扩展能力有限,核心下单流程的优化和性能测试就成了重中之重,我们的开发人员把整个性能测试环境搭在自己的电脑上。就这样一步一个脚印,很多同事加了一个多月的班,不断优化,最终在大促前两天,通过去事务的方式完成了性能测试,最终顶住了“12·21”当天系统的压力,让1号店的这个节日有了第一个美好的开端。

2012年的“12·21”就要顺利得多,系统Service化已初见成效,核心的库存和价格Service已经稳定且高效地提供着服务,核心业务流程已基本稳定。业务上的需求总是不会少的,这次给我们的挑战是一个抽奖大转盘,这个转盘可以抽抵用券,也可以抽到实物。第一期开发出来的转盘由于业务复杂,点击一次反馈时间要3秒,完全无法满足用户需要,通过不断的程序优化,最后通过去框架的方式优化完成,让转盘运转如飞。

“这次是真的秒杀,2012年12月21日在1号店可以1221元买iPad mini”,这是当时的推广宣传稿。那时候这个产品才刚刚出来,外面都要比官方价还要高,直接转让利益超过1000元。而这对系统来说是一次很大的挑战,这么大的利益很可能带来很多秒杀机器人,再加上真正抢购的用户,在抢购瞬间形成对系统的脉冲,导致系统出现问题。对此我们又临时准备了防秒杀器方案,一方面让真正抢购的顾客可以享受到优惠,另一方面也防止秒杀机器人对系统的冲击。21分准点开始秒杀,用我们运维同事当天见到我的原话来说,“我从没见过系统一下子在监控平台上全部高负载报警”。虽有高脉冲,但是很快自行恢复平稳,整个系统的稳定性经过实际检验又上了一个新的台阶。

牛奶也疯狂

经常跟朋友聊天时大家谈起1号店总会谈到它的进口食品,尤其是进口牛奶,这是1号店重点打造的拳头品类。2014年3月18日,我们搞了第一次牛奶吉尼斯,挑战30个集装箱的牛奶,预计在4小时内抢购完成。完全没有想到牛奶有这么疯狂,五折的牛奶以接近秒杀的速度被疯狂抢购,由于承载这块业务的技术处理能力不足,业务隔离也未做彻底,导致部分渠道用户大量出现访问不稳定的问题。对于已经发展到2014年的1号店系统来说,已经许久没有发生过这样的情况了。系统发展速度快,各个业务间耦合度也高,一旦有一个点出现问题,可能产生的影响就越发广泛。

针对出现的问题,最核心的还是优化程序,对相关功能做好压力测试和Capacity Planning,明确各个系统之间的依赖和联系,并针对流量脉冲进行全链路优化。

3月18日,网民用时52分25秒抢空1号店30个集装箱、总计60万盒进口牛奶,5月29日,仅用时5分47秒60万盒进口牛奶就被抢完,比此前快了将近十倍。

大促常态化

随着电子商务业务发展和行业竞争,各类促销更是越发火热,不算固定的几个大促日和周年庆,每个月都会有几次全媒体(包括硬广告、软广告、互联网广告、社交广告等)的大促宣传脉冲。而且每次主打的卖点都不一样,选择的渠道也不一样,相对应的对口系统也都不一样。

市场行为的改变就给我们技术人员带来了更大的更具变化的挑战,从原来主要是核心下单高流量脉冲变成多应用系统多模块高流量脉冲的挑战,从原来每年几次里程碑大促脉冲变成常态化流量脉冲的挑战。

面对这样的挑战我们提出了大促常态化的概念,具体包括以下几个方面。
**
1.首先应用必须要高效**。所有核心业务以及相关链条上的应用都必须做好自己的Capacity Planning,有水平扩展能力和容错能力。
**
2.其次是访问链路优化。**对产生脉冲流量的应用提前做好链路优化,从最前端的各种网络设备开始,到后面的软负载、反向代理、缓存、应用服务器、数据库等要全链路进行优化,并深入了解各个应用的依赖关系,有条件一定要做隔离和限速,保障在脉冲流量到来时既有宽敞的河道又不会影响到其他正常核心业务。

3.再次就是有稳定的私有云系统。核心网络、带宽、数据库要有稳定的HA并有冗余,应用服务器要保持一定的后备资源,以私有云的方式可以快速稳定地进行资源调配。

4.最后就是有一支了解业务又精通系统的稳定的支撑团队。互联网的人才是核心竞争力,可以在飞速变化的环境中不断调整、不断拼搏,采取合理合适的方式为业务保驾护航。

作者简介
image

邱仔松

十年互联网技术与管理经验,2010年起在1号店先后负责技术部流程管理、商城研发和基础平台工作,在1号店亲身经历了电商业务与技术的快速发展历程;个人擅长换位思考和沟通。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章
最新文章
相关文章