电商4

华为商城历战经验与教训（五） [分享自博客] [原创] [精华]
孙扬 转载了 马义 的博文  【查看原文】【转载时间：2014-08-11 14:13】

天行健，君子以自强不息。——《周易 乾》



第五章、路在脚下

二十、荣耀狂欢

原定4.18日，搞一场荣耀的大型活动，因受对手节奏影响、营销需要，提前到4.8日，定名，荣耀狂欢节！我们知道时，剩下时间不多了。又是一场遭遇战！

提前10天，对我们来说，实际相当于压缩了两个周期。一些原计划要几轮灰度上线的方案，只能减少线上验证次数，甚至直接上线使用，这就带来很大的质量风险。

3.18日才刚刚完成了主站放出，还需要多几轮抢购的压力考验，将可能存在的隐患发现并解除。3.22日刚刚完成架构优化版本上线，分库显然不可能短期完成。为了应对全天可能的巨大流量冲击，需要考虑周全。而大量订单产生之后的交付环节，也是需要进行优化的。为了应对4.8日可能的风险，我们主要考虑了以下手段：

1. 数据库优化； 这要感谢周边部门的帮助，有业软的DB专家，有2012的专家，帮助我们进行了数据库性能优化，包括SQL优化与参数优化的工作，效果明显；

2. 多商品抢购； 在现有抢购方案基础上，进行改造，实现一次活动多个商品，以支撑4.8日业务需求；

3. 提前实现流控； 我们赶在4.3日活动中，灰度使用了流控功能，这是我们保底的武器了，一旦某服务流量过大，就进行限流；正常需要多轮的灰度上线，在此，只能一轮就正式上线了。当然，在短短的时间里，将主要服务实际的性能指标弄准，也花费了大量精力；

兄弟们持续鏖战，憋足了劲！最终，虽然时间极紧，还是完成了既定的动作，到4.8日当天，成功支撑了三场抢购，并成功完成超历史的订单交易，达到预期的业务目标！在和京东等高手同台竞技之中，没有掉链子，获得成功！

江峰总抽空到研发办公区，观看作战情况，给大家的工作给予了肯定，这是对研发兄弟最大的鼓舞！

4.8日，更多的故事发生于运营环节，与对手的斗法，就不多讲了。整体来说，4.8日是波澜不惊，唯一有点小惊讶的，就是流量峰值有些高，让某公有云感觉到了压力，这是其保障组成员的说法。瞬间超过XXG流量，对带宽弹性要求还是很高的。以我们原有机房的带宽，是远远不够的。这家公有云，一个机房有数十G带宽可用，这是其提供云服务的最大资本。事后的分析，发现相当的流量可能来自黄牛机器，并且也是租用各公有云发起的大量并发请求。不过，我们事前有准备，改变了一些算法、流程，让那些黄牛工具失效了。是不是来自对手的捣乱行为，就不得而知了，没有影响到我们的活动正常开展，这就OK。

最终，花粉们度过了一个愉快的花粉狂欢节！当然，对我们来说，算是度过了最艰难的阶段，4.8日得到的命令，可简单理解为——再出问题，就放长假！还行，没被整趴下，又赢得一些时间，继续进行后续的优化。



二十一、乌云朵朵

长期以来，黄牛如附骨之蛆，无法除尽。当然，实际上黄牛也是某种廉价渠道，从商业上来说，黄牛不能泛滥，也不能全无。完全没有，对传播并不是好事。多次以来，各种手段，看到的都是“正常”的黄牛现象，没有看到我们担心的恶意攻击，慢慢地，我们也有些放松了精神。不经意间，突然，乌云出现了！

7.1日 荣耀6的抢购活动，一如预期，黄牛群冲杀过来，高达4.2亿次请求，创造了商城新高。当然，对于这些有预期的大型活动，我们会采取一些变招，将那些机器手段进来的捕入陷阱，当然，对于花钱雇人抢购的行为，就放过了。捕杀黄牛的策略，也是一时紧，一时松，这也让黄牛摸不着头脑，不知道我们出什么招。

夹杂在4亿多次请求之中的，有4千多万次恶意请求，这是以往都不曾见过的，这是个新动向。这些请求，全部是非正常服务请求，不可能出现的，其目的显然不是抢购，要么是试图扫描漏洞，要么是试图攻瘫系统，用意险恶。伴随在海量的黄牛请求之中，打我们一个措手不及。好在我们的流控机制发挥了作用，当然有流控发生，就会影响到部分正常用户，有些用户感觉访问有些慢，有些看到“花粉太热情”……。都发生流控了，应该算是太热情吧，虽然不是普通花粉，但黄牛也可以算是特殊粉吧：） 随着终端市场竞争的恶化，商城可能面临的恶意攻击也越多，也许我们也需要考虑蜜罐技术的分析、研究与实施，急需专家啊：）

7.23，又遇到意想不到的情况，虽然用户层面感受不明显，就是不太容易抢到，用户与流量对不上，我们发现了异常，最后追查，发现是某公有云平台刚升级了其清洗子系统，数据没做对，我们的流量一冲击，就有请求被清洗了。每次活动租个几小时服务，公有云提供了很大的便利性，但同时，也带来风险，公有云会有不可见的变更，是我们完全不可控制的。

7.24下午，流量不大，大家都没在意。可是突然出现主库死锁。原本认为我们已静态化的页面不会有问题，可是还是遇到没想到的问题。页面实际已到达本地，但是其中有个用户状态是需要动态获取的，而页面的渲染是在动态请求完成之后，因此，静态页面用户仍是不可见。魔鬼都在细节之处，我们努力了很久，完成的静态化，就因为其中的一个小点，差点出事。好在我们应急很快，直接将动态请求给个空文件响应，至少让网站活着！静态化是否彻底，特别需要关注其中的动态请求在异常下对静态页面的影响，这真是教训。而主库的问题，在我们以为有了流控，可以拦截过量负载时，遇到高手了！其构造的URL完全绕过了我们的流控，大量工具请求直接穿透到后端了！到了当晚，更是持续不断地攻击！真正的恶意攻击，越来越多了！以后，我们将面对的，会有更多恶战！还没纳入正式武器库的URL白名单功能，原本还想要再多考验几轮的，当晚立即起用。与“他们”的交战，才刚刚开始！当天，算是1：1，打个平手。下午，他们打了我们一个措手不及，经过紧张分析日志，搞清楚其攻击手段，晚上我们增加防范，让其未能得手。

又要规划新武器，丰富我们的武器库了，对手下一次的武器是什么？不知道。真心希望喜欢互联网攻防游戏的同学以各种方式加盟，公司搞网络安全的专家，可以露一小手了：）

看看对方的招术，在5分钟里，使用了2万多种URL，来源成百上千的IP，每秒超过6000次持续攻击，看看神奇的URL，这玩法，事前真没想到：

/%6fr%64e%72/c%6fn%66i%72%6d?s%74%61%74%65=%31&s%6buI%64s=1%3175

/or%64%65%72/co%6ef%69%72m?s%74ate=1&%73%6buId%73=1%31%37%35

/or%64er/co%6e%66%69%72m?sta%74e=%31&sk%75Ids=%31%31%375

/o%72der/%63%6f%6efir%6d?s%74a%74%65=%31&s%6b%75Id%73=1%31%375

/%6f%72d%65r/%63o%6e%66i%72%6d?s%74%61%74e=1&s%6buI%64s=%3117%35

/o%72%64e%72/c%6fn%66i%72m?s%74%61%74e=1&skuI%64%73=11%37%35

……

有兴趣的同学，可以翻译下：）



而造成DB死锁的问题，还是细节，mysql在网上查了，居然有个魔鬼数字，我们用的一个自增量主键，并发锁超过200时，DB会判断成死锁！这种细节，不真正遇到时，可能都不容易想到。对手绕过流控，让我们就触发了这个陷阱。详细的过程还原，我们花了很长时间在还原细节，大致判断是受此影响，但并未完全重现。

之前，我们还遇到的一个行锁问题，我们用的是INNODB,其锁是加在索引上的，这与ORACLE锁数据块是不同的，这里要非常小心。这个可从网上查到：

InnoDB产生区间锁（也叫间隙锁）的原因主要有一下两个：

  1. mysql为了避免幻读，采用repeatable read事务隔离级别

  2. mysql binlog采用statement格式，因此需要使用innodb_locks_unsafe_for_binlog=0

避免幻读和记录锁加在索引上这两点就能够得出区间锁的影响范围了，对于唯一索引，不同的session通过索引记录加锁不产生区间锁。对于非唯一索引，于唯一索引的区别是：在索引记录上加锁，会导致该索引记录与前后索引记录之间的区间会加上区间锁。当你以为是行锁，实际退化为表锁了。我们就是一个后处理工具中，遭遇此陷阱的，产生了一个很隐性的BUG。

另外，有个小教训，DB的连接数配置，server端一定要大过Clients端总和，尤其要关注，在扩容Clients时，增加某APP时，要核算连接数，很容易忘了这个细节，务必给管理员连接预留几个，否则一旦出现过量请求，连接数用完，会导致管理员登录不了，容易抓瞎、误判。

太多细节技术问题，希望公司内的各专家也拿出来分享吧，很多时候，技术不一定需要高大上，能熟知细节非常重要。

722~724三天署飙节，收获销量的同时，给我们IT带来了新的问题。一些商品转成正常主站购买，结果还是会引起黄牛抢购，主站的复杂流程，既难以支撑太高性能，也难以防范黄牛的工具。在主站与抢购模式之间的选择，又将是一个非常纠结的事。这又是个新的乌云，就在头上，暂时还没想好应对方案。

也许，这朵朵乌云，会打乱我们下半年的既定节奏，无论怎样，我们面临的压力显然只会增加，每一步前行，都有如履薄冰之感，且行且珍惜吧。



二十二、隐患排查

7.1日，提醒我们，敌人虽不可见但无处不在，必须要防患于未然。在7.1日的攻击之中，还有个明显特征，就是通过WAP访问。对于WAP服务，我们还没有腾出精力（资源总是有限的），考虑到一直以来WAP的流量都占比不高，优先级就放缓了。7.1日之后，我们也赶紧将PC侧的经验，加快复用到WAP上。

另外，我们又对组网方案，系统设计进行了排查，还是发现了一些隐患。我们为了隔离问题，对系统进行了拆分，但我们实际组网上，还是采用了合设方案，尤其是数据库合设，是会有隐患的。我们目前只租用了一家公有云，在7.1日其管理系统出现崩溃，让我们极为紧张，而且多次活动中，大流量冲击，也导致这家著名公有云出现服务质量下降，大量丢包出现，这是非常危险的事，大部分的流量都在其上，需要考虑组网备案。

虽然我们排查了，但7.24还是受到突然的攻击，我们在互联网领域的经验，还是相当缺乏的。运营商的业务网络环境，要干净得多，相对封闭的网络，没有那么多攻击，也没有随时可接入的入口，人为破坏是个极少发生的事，而在互联网，是随时发生的事。对于运营商业务，我们只要关注客户需求就行，但在互联网领域，必须要关注可能的敌人，因为，破坏是这里必须考虑的场景，假如对手或黄牛抢走了大量首发机器，可能造成的是商业上的危机，制造恶评、降价销售、掺假销售等等，雇佣水军、黑客、肉机，对网站的攻击、骚扰等等，还有很多我们都不一定想得到歪招。对于对手的防范，是我们必须要做的功课。互联网而且还是2C业务（我们其实也有2B业务，就没这么好玩了），注定我们必须要关注对手、分析对手，和运营商业务还是小有差异的。在这个领域，我们可能还没上小学，要补的课，还有很多，很多。



二十三、网络陷阱

         Proxy陷阱

         对于涉及交易的系统，尤其要小心proxy陷阱。多年前，mycooo遇到的问题，经常发现用户错位，A用户登录，看到的是B用户的发言。后来发现，这就是由于A，B同在一个公司，用的是同一个proxy。Proxy的缓存机制，很容易造成这种问题。对于应用层来说，需要注意如何确保唯一性。如果涉及交易，要有身份的最终确认。在设计上，能减少状态依赖，最好是全程无状态，能更好地避免问题。

         加速陷阱

         有天半夜，我们的领导发现一个问题，验证码总是不正确。结果我们定位半天，发现移动网络，有各种加速网元，其加速规则不清楚，但都离不开基本的缓存。即使网页指明不让缓存，带上参数，也不能保证。这大概是互联网与电信网的一个差异，一个非常标准，大家都严格遵从，另一个是，似乎有些标准，但有很多人不遵从或不完全遵从。

跨网陷阱

在中国大地上，基础网络的互通是个难题，即使在同一个城市，跨网互通也是非常困难的事。这不是技术问题，这是利益问题。网络是连上的，但就是不通。奇葩的单向收费政策，实际是制造了垄断。不知道，三家合营的铁塔公司是否解决了互通，但十有八九会造成新的垄断。正是由于跨网陷阱的存在，各种多线机房应运而生。当运营商不能互通时，就得有中介，当年做移动某项目需要多线带宽，中移动不能去找另两家，只能通过中介。

我司是典型的双线网络，而且我司的网络环境更为复杂，有多城市，还有不同区域，尤其iaccess很多人喜欢挂着，于是经常出现难以访问VMALL。这都是跨网不通导致的结果。我们的主机房之前也和公司一样，是个双线机房。尽管我们的DNS配置，会针对不同网络走相应线路，普通用户就不会遇到问题，公司内就不行了。中间经过了proxy，无法保证线路对齐。为了解决这个问题，对公司内网进行特殊配置，专门走了一个BGP IP，再转到我们的主机房。而挂上iaccess，基本就肯定跨网了，有时离谱的iaccess会用到海外IP。因此，才会在心声上出攻略，让大家不要用iaccess。有人可能会问，为啥访问其他网站没事呢？原因也简单，因为大网站肯定都是多线BGP机房，没有跨网问题，而且CDN资源足够，CDN也无跨网问题。现在，主机房也有BGP IP了，虽然带宽不是太多，够解决公司内网访问了。



二十四、内购难题

        内购，作为一个业务，希望大家记住一点，经济学中强调在自由状态下，自愿的交换产生增值。如果还要多说点，理解下羊毛不可能出自狗身上，差不多就这样。至于业务承载的各种诉求，就不是技术问题了。

         有人希望W3登录，就登录了VMALL，还有人说，干脆就工资里扣，这些想法都有其合理性，只是这些不是纯技术问题，不是VMALL研发能单方面解决的，信息安全、税务审计，都不是能容易过的关。最终，还是要去定义清楚内购这个业务，目前我们只能在方便与便宜之间，找点平衡。

         需求简史：

给内部员工每年发一部手机；（有严重税务风险）

每年给员工发一定额度商城代金券；（有价格管控风险）

每年给员工发几种打折券，不同机型根据市场定价确定某种折扣；（已执行过一期，再执行二期中，大家可以去一键领取）

内购商品在外部要不可见；（基于价格管控需要）

外部套餐不能在内部再打折；（商业本质）

其他商品也想给内部员工派福利，各个优惠力度不同，无法用券，一口价出现了；

……

最近，套餐、运营商号码业务也要往内购中放了，没准哪天团购、抢购也放进内购了。

慢慢地，我们估计内购早迟变成一个完整的独立商城了，为此，我们考虑要系统性改造了。一个内购频道不行了，应该是内部的一个购物平台。此平台，只能通过公司内网访问。但需要解决统一商品管理，否则运营部又增加工作量了，另外，还要解决回家支付问题，不是每个内部员工，都能通过内网完成支付的，proxy权限不够的人还是很多的。方案还在细化之中，还有一些运营的难点要解决，很难有完美案，最终还是权衡、妥协吧。



二十五、继续前行

所有的互联网系统，都是在业务高速发展中，不断进化系统架构，我们的业务只能说刚刚起步，系统架构的优化也将会不断发生。我们现在的购物体验，还有很多不如意处，需要我们去不断优化。我们的性能优化，在刚刚完成的通宵升级之后，算是取得阶段性成果。对我们来说，一个阶段的结束，同时意味着下一阶段的开始。我们内部，花了些精力在进行下半年及明年的技术规划，想要做的太多，节奏就是最关键的了。搞研发要是能用FPE就好了，可以改到无限资源，可以同时完成想做的各种事情。理想很丰满，现实很骨感，在有限的资源约束下，如何选择就是最重要的事。我们后续的技术重点会考虑前端优化，实现快速定制，后端优化，提升运营效率。我们的海外项目，可能会有爆发式增长，要做的事很多，要学习的很多，估计摔跤的次数也不会少。但我们会始终保持奋斗精神，因为：



我们拥有持续的鞭策：）



我们还有强力的牵引：）



现在我们的进步确实不够快，但我们不会停步，记得老家农村有句谚语——“不怕慢，就怕站”，只要不停步，乌龟还赢了兔子不是嘛。我们将坚定地继续前行，荣耀在路上，路在我们脚下。



后记

不写文章很久了，写此文，相当犹豫与纠结，原因大家都懂的：）

知道的越多，不知道的将更多，唯一能做的，就是心怀虔诚，竭尽全力，支撑业务的发展。

时间似乎不长，但事情多了，尤其是痛苦的经历多了，时间就显得长了。一些故事细节记不全了，另有些数字不适合透露，不能保证完全符合实际。道可道，非恒道也。能看到的，只是我能写的，写不出的，是已辗死在时间巨轮之下的“真实”。我不能保证写出的定是真相，尽力保证的是写出的不是假相。

作为经验总结，个人是想到哪就写到哪，难以写出应有的精彩，实际发生的故事比这精彩十倍，本文就权作砖头扔出来，亲身经历的很多兄弟，有空再分享吧。相信随着业务的不断发展，故事还会不断，精彩与痛苦也会继续。欢迎对VMALL有兴趣的同学私聊，更欢迎各种形式的加盟：）

这里更多记录的是故事，干货不是太多，需要干货的，欢迎加盟：）

我们的SE将会抽空写写复杂网络与验证码，那是个真正的技术高手，写出的内容一定是干货，比较有料，敬请期待：）

参与攻关的兄弟们，尤其外援专家们，有空也分享一下，这篇引玉的砖头，就算没白扔了：）

名义上，当年参与mycooo微博项目的兄弟，算是公司内最早一批玩互联网的喽。记得当年组织调整时，曾希望有个兄弟留下，但他还是铁了心要去互联网部，让人挺伤感的。现在回想，这可能就如同“自由”一样，当没有“自由”时，不知道其珍贵，可一旦拥有之后，就不会有人再放弃。这可能就是我司很多人可转去互联网公司生存，却鲜有互联网公司的人能入我司生存的原因之一吧——文化土壤不同，互联网天然有种自由的气息。仍记得当年思创小楼上，幼稚但自由的创新。电商，应该算是鼠标+水泥的业态，最近听京东高管谈，腾讯做不好电商，原因就在于电商尤其B2C中需要零售基因要多于互联网基因，似乎有些道理。这样看来，相对于纯粹互联网业务，电商感觉应该更能适应我们的文化，能参与其中，幸甚！

埋头干活，容易失去感觉，陷入自我设置的围栏，需要跳出来看看，花点时间作这个小结，分享出来，能获取更多外部的信息回馈，让我们能更好前进，这也是这篇分享的初衷之一。

很多的评论，有很多的鼓励，也有很多的提问、建议以及批评，有些不方便回复，有些在后续文中或有涉及，就不一一回复，在此感谢所有关注VMALL的兄弟姐妹！感谢给予鼓励的新老战友！更要感谢一直以来，承受着巨大压力，努力拼搏的众兄弟姐妹！



分享落幕，商战继续，精彩故事待尔述！——诚邀加盟