电商1

第一章 出师不利
截止到13年12月初，VMALL已支撑过很多轮的活动了，包括荣耀2，P6，Mate等著名产品，所有的活动都未有超过荣耀四核的流量与压力，太久没有大战了，现在大战来了，荣耀3C突然要搞活动了，说实话，对其能达到什么程度，是没有概念的，因此一场未能提前充份准备的战斗就这样不期而至了。

一、风云突变
VMALL的故事，更久的源头就远了，还是将镜头拉到2013年12月17日，荣耀3C一天预约近百万，远远超出我们的预期，在荣耀四核首次搞这种抢购活动，在预约赢smart车的刺激之下，在QQ全力引流之下，三天预约了80多万，那曾是个顶峰，在一年多的时间内，我们就未曾再达到过如此高度。此前和营销、市场就流量进行多次沟通，大家的意见都统一认为按P6流量准备方案与资源。
面对突然的变局，当天召集骨干进行紧急会议，首先对预约用户进行了分析，其中有大量用户帐号是虚假Email，有很多是机器预约的。从其他部门也得到信息，小米在荣耀3C发布会当晚，召集各路水军、大V研讨对策。
问题1：对手可能出什么招？
问题2：我们需要进行怎样的防范？
这是我们当天必须要尽快明确下来的问题，一周之后，就是正式抢购。

对于问题1，我们都很纠结，这是明和暗的斗争，我们身在明处，对手在暗处，看不见但无处不在。用机器手段预约这么多用户，目的何为？ 从人性角度出发，动机在哪儿？ 既无名，也无利。
如果说对手买通，也难以说通，这样造成更多预约用户，完全是正面宣传。
会在抢购期干些什么？
如果都被他们抢了，别人抢不到，那造成更为饥渴状态，也是正面宣传。如果故意黑死网站，除了对当期销售有负面影响，对商品角度，也一样会造成更为紧俏的正面影响。且首发的是多个平台，有经历大风大浪的京东，也不是那么容易被黑死，估计对手也不敢啊。
再换位一下，假如我们是小米，我们会去帮助宣传荣耀3C吗？即使是负面宣传，都不合适，容易利用自己很强的互联网影响力，帮助了对手。如果我们是小米，最好应该是不让荣耀3C与小米任何产品产生关联。
为了求证，我们立即到小米论坛去找相关荣耀3C信息，确实从侧面证明这样海量的机器预约行为，应该不是对手所为。在小米论坛中，在当时，没有任何一条荣耀3C相关信息。我们当时就很佩服小米的运营管理，那可是远比我们论坛大得多的人群，能管住声音，是很用心，也很有执行力的。
回到我们自身，当时给出的判断这些大量无效用户，是由恶意的人制造，先做准备，再进行攻击前准备。
结论：大量是无效的用户（虚假Email帐号），有效用户规模虽然仍会超过荣耀四核，但超过的不多。正常用户的抢购压力应与荣耀四核相当，但面临恶意攻击的风险很高。
这个判断，现在回头去看自然是错的，但再回到当时，以我们当时的水平、经验以及掌握的信息，让我们判断不清。这个判断的错误，给我们带来的后果是非常严重的。

时间留给我们的只有一周，抢购既定的方案，是从荣耀四核抢购方案逐步演进过来的，经历过很多轮的抢购活动了，但我们知道，面临的是新问题，新风险。
基于问题1的判断，我们开始了问题2的讨论，主站可能的入口太多了，受攻击的点太多了，一个一个分析软肋已没有这个时间，当时大家紧张讨论，最后明确了几点：
1.       紧急扩容服务器，用来增加扛攻击能力，同时，用于应急预案设备。
2.       带宽已无增加可能，再扩容需运营商施工，这个周期已不可能。
3.       最坏的情况下，保住活动，三级有损服务，最低级情况，记录抢购用户，进行后处理。
4.       真要是DDOS攻击，以我们的带宽及服务器资源，除了认命，挂免战牌，没什么招了。

我们的方案：
主  案
采用既有抢购流程，完成正常商品抢购、下单。 基于历史数据，可承载在线并发用户20万。
预案 1
在活动开始前，如果并发用户超20万，或者主站访问拥塞，启动本案. 
流量由LVS切换到NGX分发服务器集群，利用NGX的分发策略，对后端服务分两组，确保组与可损组。确保组有两类服务，纯静态部分由另一组NGX服务集群构成，用于提供静态页面服务；动态部分只有写临时订单文件服务（不写DB）的集群，该集群由Apache+Tomcat组成，Apache提供基础性过负荷能力，控制向Tomcat的连接请求量。NGX首次使用，性能没有测试，在网络上有介绍，性能很高。对于可损组，实际是主站原有系统部分，如用户鉴权等。
预案 2
在预案1的基础之上，若出现用户数很少，无法登录，或无法获取用户登录态相关信息，则更换预案1中的静态文件，收集用户的手机号码、用户收货地址信息，记录文件，后处理再生成订单。
 

方案上报各相关部门备案，开始紧张的方案实现工作！
 
二、山雨欲来
12.25日凌晨3：00，叫来夜宵，大家边补充能量边讨论可能存在的问题。我们的预言帝叹口气，预案准备太不充分了。是的，一周时间，准备太仓促，使用的NGINX还是我们从未实战过的新系统，我们最后的底牌能否管用，不知道。
12.25日凌晨5：00，预案总算功能测试通过，显然，我们已无时间进行性能测试了，赶紧进行现网部署、验证。
12.25日凌晨6：30，所有环境部署完成，各业务流程都在现网跑通。
12.25日上午7：00，大家买了早点，吃完。让大家小憩一下。
12.25日上午7：00~8：00，寂静！暴风雨前兆！独自坐在会议室，面对乱麻一样的白板上各种讨论，最后再全面整理着思绪。敌人会从哪儿攻击？
12.25日上午，8：00~9：00，各单位陆续就岗，作战室开始工作。已登录用户5万，暂时未见系统异常。
12.25日上午，9：00~9：30， 流量激增一倍，用户登录10万，预期用户肯定会超过20万，作战室，启动预警。

三、狂风暴雨
12.25日上午，9：30~9：40，新增2.5万用户，主站系统开始感受到压力，页面响应开始有些变慢，仍在可接受范围。
12.25日上午，9：40~9：50，新增4万多用户，系统压力明显增加，网络负载很重，有部分系统开始告警。该关闭的服务，立即关闭。
12.25日上午，9：50~10：00，新增7万多用户。已越过警戒线！系统已产生大量告警，网站访问已出现较重卡顿。作战室内紧急讨论，先启动预案试试！
于是，试着开启了预案设备，然而，惊讶地发现，切换了不到几秒钟，预案设备全部宕机！又手工启动一次，结果一样！冲击力之强，完全超出了我们的想象！
12.25日上午，10：00~10：05，5分钟里又激增6万多用户，已超过30万用户堵在抢购门口了！现在预案设备出问题，原因来不及排查，只有3分钟就开始抢购了！我们在作战室内看着激增的流量，拥塞的网站，大量系统告警，空气都凝结了。只能孤注一掷，就用之前老方案去扛了！
12.25日上午，10：05~10：08， 在各种卡堵之下，还是又新增了6万用户，差不多40万登录用户堵在门口，还有一群未能完成登录的堵在各条路上，网络带宽达到极限。到点了，开闸！

四、一叶扁舟
如果用什么来形容当时的心情，立即闪在我脑海中的，就是《完美风暴》中船长Billy Tyne最后决定，掉转船头，直向风暴中心！最后船撞在如山的浪墙之上，失速沉没！
可怜的活动抢购系统，确如在茫茫大海之中，孤独面对狂暴风雨的一叶扁舟，随时会被巨浪吞没！
开闸之后，我们紧张地盯着订单，时间一秒一秒地过，每一秒都象是一记重锤敲击在心头，心中默算着，普通用户下完订单的时间。
10秒！首个订单出来了！
耶！大家都紧握拳头！活着！我们的小船还没沉没！虽然艰难，但顽强地活着！
网络带宽处于高位，很多子系统出现异常，不能响应请求，最不可理喻的，是大量异常与告警，但服务器CPU并没耗完。
拥挤！拥挤！还是拥挤！
但活动子系统，还坚强地活着，它的性能无法达到预期的能力，在前面很多环节的拥塞，会让很多人不能顺利地完成下单，尤其很多人会去重新刷页面，实际基本就更没机会。订单每秒都在增长，没有期望的快，但在稳中有升，在逐步提升下单速度中。

有些服务器始终可以正常工作，有些服务器就是不能正常工作，内部局域网有异常丢包！

五、风暴退去
10：16分，活动结束！
10:30分，活动结束十几分钟了，压力仍然巨大，又新增十几万用户！
12：00，用户达到60万人，中午时分，压力开始因饥饿而缓解，人总是要吃饭的。系统访问总算恢复正常。
下午，主要骨干休息，后备组收集各系统日志！将原关停服务逐步恢复！

第二章、快速反击
输得体无完肤，还能不能再战？敢不敢再战？
示弱！但不怯战！
拿着小学算术（见后），与各周边协商讨论方案，提出降低部分体验，如页面精美度需要牺牲，用户购物要分段完成等，最重要的，主站在活动期间隐身示弱！最终方案获得认可，全力以战！
六、输无可输
12.25日 19:00，作战室几个骨干一起坐下开会讨论。
气氛很压抑沉闷，大家已很疲惫，但结果很差，历来新品首发，总是VMALL超过其他平台，今天未达预期，系统被拥挤得不行，在心声上也被痛骂，大家都深感惭愧。
会议开始的几分钟，大家都在沉默，看着大家的神态，我也重新整理着头绪。
首先，我们必须接受这个事实，我们的方案没有经受住考验。
至于原因，我们还需要花相当的精力去追查，但显然也不是几天时间能查透彻的，各系统日志都是海量的，要分析出根本原因，核心环节，是要花费不少时间的，而下次面对的问题可能不同，而下次就是12.31日的二轮抢购，留给我们的时间只有5天！因此，我们先保留现场，保留各类错误日志，待进一步分析。
毫无疑问，我们现在最重要的是重拾心情与信心，要打一场快速反击战！
其次，我们退无可退，31日二轮抢购，压力不会降低，可能更高。正如前面的分析，系统拥塞，会被动地成为3C热度上升的助力器。再加上，二轮产量远远超过首轮，必须要趁热大量出货。系统如果再瘫，那就没有然后了。
基本问题点：
1.       预案失效。 NGX分发集群，完全未能扛住流量。 预案设备中，出现大量内网丢包，必须要查明。这让我们死得不明不白。
2.       不符合预期的动态请求量。首页、3C详情页都是静态化的，按理用户应主要访问的就是这两个静态页面。为什么会有大量动态访问？为什么不符合设想的模型？
3.       看不见的瓶颈。有些服务器坚强，有些服务器脆弱，很多服务器并没看到性能达到瓶颈，为什么。这和测试模式差异很大。
（这些问题，我们联合企业云一起，在二轮抢购（12.31日）活动之后，结合31日现场数据观测，参数调整，最后给出相应的分析。有两个底层的问题，一个是云平台组网方案中依赖iptables的安全策略，VMALL的分组、分域的网络安全策略较为复杂，iptables性能出现瓶颈，这在31日现场观测中被印证，通过临时调高参数规避；另外，VMALL的虚机数量庞大，虚拟机在物理机上分布有问题，面对这种同时达峰值的压力，多台虚机在同一物理机上，造成物理机瓶颈。）
应对31日的方案要点：
1.       紧急请求企业云支持，紧急增加设备；
2.       紧急请求企业云支持，将出口带宽扩大一倍，将主、备两路变为双主来紧急应对；
3.       紧急申请一批服务器，独立构建活动系统，并要求分散虚拟机（虽未分析出原因，但感觉虚机分布可能有问题）；
4.       其他业务机房紧急申请一批服务器，作为节流阀之用，进行流量调控；
5.       暂停冒险使用NGX作法，仍采用多组LVS，应用层采用已成熟使用的Apache+Tomcat技术；
6.       主站系统过于复杂，软肋很多，在完成主站优化改造前，先示弱，抢购期主站隐身，全站只提供抢购服务，其他服务停止；
7.       抢购活动先做减法，将复杂逻辑去除，牺牲局部体验，保证全局体验，功能简化到极致；
8.       静态与动态隔离，静态部分用服务器数量去扛，为保障带宽，所有页面元素精简，控制页面大小；提示禁止刷屏，页面截获F5；采用本机时间，避免上行压力；
9.       页面各部分大小要求：全部图片大小不得超过50K；各JS+HTML等大小累计不得超过20K；上行请求不得超过2K；（可参见后面的小学算术）
10.   抢购活动，只干一件事，到时间点，用户一个点击即上报用户信息，服务端按时间排序。服务端分多组完全独立，各自平均配额，用完即止。
11.   抢购配额全部用完，就活动停止。活动停止后，进行后处理，将合法排队用户以提交时间为序生成订单。
12.   所有订单生成后，按区域放开主站，让用户完成订单地址填写并完成支付。
最大的风险，估计就在于主站开放，初步评估后处理需要半小时。