写在前面

电商是什么?拆开来讲就是电子和商务。之前最关注的是电子,就是我们所说的技术。而商务就是业务。之所以简称为电商,是因为两者非常紧密的相连着。

今年是我在魅族电商业务部的第三年:之前从Flyme到官网、论坛等业务我都经历了一遍;电商业务对于我来说是最有挑战的业务之一。在从事电商的运维后,特别是经历了双十一、大型抢购、秒杀活动后,更加真实的清楚了电商的真正含义,得出了之前从未有过的感受:

1、 千万不要低头做技术,学会真正从业务角度去思考。

2、 不要低估技术的力量,技术是可以推动业务的。我们站在技术这一方,与业务是互相影响互相牵引的。

3、 精通你手中的业务,是每一个环节。小到一张优惠券的生成和去向的过程。

当你对手中的业务非常非常熟悉,甚至有一种“我是否能做产品经理了”的错觉——当你熟悉到这种境界,你会发现曾经低头做技术时所发现不了的东西。因为随着对业务理解越来越清晰,你自然会知道架构中哪些集群是可以合并的,哪些资源是浪费的,哪些环节是需要做扩容的。你可以很好的去做架构优化,随之而来的就是更好的成本控制。你不用再去猜,这里我需不需要加机器,加多少台?这些机器是不是可以撤掉?并且你还可以参与主导业务活动。

这里跟大家说了一个真实存在的故事:有一次市场部打算在某一周做秒杀活动,但是由于他们担心网站抗不住,决定将活动分在五天分别举行。但是基于对业务和技术的熟悉理解,我认为活动完全可以在一天内完成。于是,我从了两方面工作:首先,在活动来临之前,通过活动类型分析、流量来源分析、产品热度分析、用户习惯分析等等,估算好了大致流量,提前做了架构扩容。其次,热度高和热度一般的活动安排在了在用户最活跃的时间段,合理安排秒杀活动顺序。然后很有信心的告诉市场部同事:“你们要做的这期秒杀活动在一天内完成绝对没有问题,放心去做”。

最后,活动比预期更成功,用户反响非常好。既保证了用户参与度最大化,也保证了网站的稳定。后台同事也夸奖道:没有想到仅用之前2/3的机器就扛过这期大活动!这都要得益于将资源合理地整合和优化。所以我认为:技术一定要懂业务,并且要吃透!

从业务到技术的备战

魅族备战双十一的工作主要分成两个部分:其一为交易前,其二为交易后。

交易前环节:我们首先评估双十一备货方案,然后从优惠力度、所争取到的流量入口资源等级评估,在下线若干非核心功能,例如服务类和保险类业务。同时,与我们的云厂商相关部门沟通合作,以获取到优先级较高的TOP接口。

交易后环节:这部分的重点工作是保障各环节服务稳定性和链路稳定性。双十一订单虽然不在魅族商城生成,但从淘系引来的订单流量量级非常之大,量变引发质变,不能用常规手段处理订单。因此,我们在业务架构上做水平拆分,水平扩容SLB集群、使用DTS,按照多线程作业的方式从淘系接口处抓取订单,在ERP系统内先行做订单格式中转,再传递到订单中心OMS处做订单处理、推单入仓等操作,随后再分批推送订单数据到物流WMS接口并完成订单入仓的操作。

业务难点及对策

整个双十一对于我们来说,难度最大的地方在于保证全链路稳定。因为仓内操作有一部分人工作业,存在效率瓶颈。如何喂饱仓内操作部分是最大的挑战,我们的订单需要赶在全网大面积订单出库前,在第一时间就能搭上首批物流运能。从出库这个环节倒推,需要每个系统之间的交接耗时尽可能最短,只处理最需要的业务,大量采用多线程作业方式,从而确保百万级订单在淘系入口抓取下来后,能以最快的速度完成订单格式转换、订单处理、订单推仓、出仓回传,每一个环节都需要对现行方案做反复多次的验证,并组织各环节做链路压测而非普通的性能压测,最薄弱的一环将会直接拖慢整个流程的效率。

从业务开始,分析此次双十一我们卖的是否是热销产品、是否有优惠产品、是否有秒杀类产品。接下来再分析流量来源,我们从哪里做了导流、导了多少流量。结合以上两点,我们能大概算出实际到我们平台的流量有多少。有了具体流量,我们就能做集群扩容、系统调优,还能评估出哪些功能可以上线、哪些不能上线。这样就可以很好地提前梳理出,哪些是可能会发生故障的点。

整体架构解读      

我们核心业务基于云厂商的服务做了多套集群,后端RS独立于每套集群。用DNSPod进行分流,分别以地区进行区分,如华东、华南等。RS搭载了OpenResty(后文简称OR)和Java,其中OR我们与Lua语言进行搭配。OR在处理大并发大流量下,比Nginx强大并且灵活很多。并且在性能上远远高于Nginx,其次能很好的做到限流,所以我们线上基本上取代了Nginx。

缓存我们使用的Redis,其中我们自行开发了zoowatchdog,负载节点的健康检查和主从切换。当初并没有合适的高可用方案,原版twmproxy没有和ZooKeeper结合的。那我们如何维护ZooKeeper上的redis数据呢?结合这些问题,我们自行研发了zoowatchdog。一方面做监控,一方面维护ZooKeeper上的Redis信息。

在数据库上,我们实现了分表分库。有一个主库、多个写库、多个读库(不管读写库都有主备),每个读库仅提供一个业务去读(因为我们业务的读写库压力都非常大,所以我们首先把写库做成多个可写入点。读库分为业务来读,每个读库仅提供一个业务去读,互不影响。)用户调度我们是根据用户ID,经过取模算法分配到不同的写库、读库上。每个库又分32张表,这里则是通过订单ID再决定具体读/写哪张表,有效地保证了在大并发下的读写效率。

三大技术点护航大促

一、峰值应对

在监控布局上,我们采用了Zabbix和CAT两套监控进行。Zabbix监控硬件、网络系统等。CAT监控业务,并且结合听云APM。报警接入我们的微信和钉钉以及短信(工作时间发钉钉和短信,非工作时间发微信和短信)。

活动系统利用阿里云的ESS弹出服务可以做到及时扩容。只需提前将镜像准备好,再设定触发规则,如负载达到多少或者定时弹出。

总体而言,流量控制工作依次为流量清洗、限流、限量、防火墙和紧急预案。在限流工作上,通过OpenResty和代码层来控制,OpenResty控制排队数量,根据网站负载来实时调整。代码层控制单个IP发起的请求数和下单数。非系统核心代码,许多功能我们都做成了开关。如此,在大并发来临时,我们可以进行降级:根据当前网站负载决定关闭哪些功能。同时我们还准备了紧急预案,当流量突破上面层层抵达系统时如果仍足以击垮网站,那么我们将仅仅保障核心用户的正常使用,非核心用户则会暂时不提供服务。

二、快速访问

动静分离,动态服务端缓存会话和热点数据等。静态CDN加速,并设计了CDN容灾架构,以及CDN流量划分。并通过听云APM做到性能监控和页面打开速度监控。主要做了一下几个优化和措施:

1.大图片延迟加载

2.小图合并,或内嵌,减少请求

3.静态资源的压缩、合并

4.静态资源非覆盖式发布,持久化缓存(进行中)

5.部分数据,异步请求,动态渲染

6.访问频率较高的页面,首页、商品详情页等静态化,及SEO优化

7.提取页面公共静态资源做预加载,预缓存

8.商城移动端首页的首屏添加样式的内嵌,保证首屏加载的可用性

9.后端Server缓存页面(如首页)15秒,以及Redis热点数据缓存

10.OpenResty限流,防止恶意请求

基于以上这些优化,我们的首屏时间控制在2s以内。

三、严治黄牛

黄牛令人痛恶深绝,这是电商行业业内共识。黄牛不仅影响了正常用户的利益,同时对应非正常的请求给网站带来很大压力。黄牛带来的流量可不能小看,完全有可能引起雪崩效应。在普通用户们正常进行网站请求时,黄牛就在疯狂的刷页面、接口;而当活动即将开始时,普通用户也开始狂点鼠标时,黄牛依旧在疯狂请求。那么,如果对于大促活动你没有提前将黄牛流量算入此次活动,很有可能影响活动正常开展。

魅族电商通过自建用户体系、活动分级、系统筛单、用户评分、流量过滤等研发,做到了行业领先的防黄牛技术。不仅保护了正常用户的利益,同样也减轻部分网站负载、运营人员的工作量。

自建用户体系:用户来魅族商城购买产品时,首先需要先建一个账号,这个账号与手机号码绑定。下单时必须是处于登录状态。那么这样的好处是什么呢?身份识别。那么建立了自己的用户体系后该怎么办呢?需要完成数据沉淀和积累,以了解用户的购买习惯、购买动机和用户活跃度。

用户打分:了解用户的购买习惯、购买动机、活跃度后,我们再通过数据分析给这个用户得出一个信用分值。可分为S、A、B、C、D共5个等级。

活动分级:当要举办一个抢购或者是秒杀活动时,可以设置一个门槛以防止黄牛参加,比如可以假设只有S级的用户才能参加。门槛等级根据活动及活动的产品热度来决定。

流量过滤:通过防火墙、OR、程序等措施层层限制请求数、下单数及排队数等,以此来控制黄牛发起的非正常请求(如单IP一秒发起100次请求,或者绕过前系统,直接请求下单接口等方式)。

系统筛单:通过已经下单成功的订单信息区进行分析,看看哪些用户是黄牛。假设这次下单成功的10000单中,有20单是下单地址或者姓名类似等(订单信息有批量生成的嫌疑)。

根据魅族的经验来看,自建用户体系+用户打分+活动分级+流量控制+系统筛单,这一套组合拳够黄牛吃撑了。 

总结

目前业务飞速增长,留给我们研发团队追赶业务需求脚步的时间并不多。所以需要以一种快速反应、快速建立的态度来应对大并发环境下各种问题,我们没有那么多时间去淡定地构建一个伟大又超凡的架构。我们只能沉着冷静的去构建最适合现状、最能快速扩展和响应的架构,以此为飞速发展的业务提供一个当下最坚固的地基。

我个人加入魅族已经三年有余,可以说是看着魅族从一个青春期的男孩,经历种种冷眼与嘲笑后,迅速成长为一个男人。这一路走来,遇到的问题从来没有少过,也曾让我手足无措、茫然四顾。如今回顾总结,从业务的角度出发,重新去审视技术本身,发现其实没有那么难以抉择和难以舍弃。坚决的去选择最适合当下的,自己用的最舒服的架构吧。

作者

刘文彬,2013年加入魅族,先后负责Flyme、官网、论坛等业务的运维、运营规划以及架构设计。现任魅族电商团队运维负责人,追崇白猫黑猫论。对架构设计、运营规划、流程标准制定有较深的理解。