魅族 11.11：架构为酒业务当歌，解读电商运维之困

双十一作为已经逐渐常规化的网购节日，被视为电商平台一年一度的大考和阅兵，InfoQ 在 2014 年和 2015 年做了两期报道，引起了广泛的关注。2016 的双十一特别报道也如期而至。

在本次 ArchSummit 全球架构师峰会北京站，设置了《电商专题：系统架构如何应对业务爆发式增长》和《阿里双11 技术架构突破》专题，来深入解读双11 等大促背后的技术故事，大会将于2016 年12 月2 日-3 日在北京国际会议中心召开，欢迎关注。

写在前面

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

今年是我在魅族电商业务部的第三年：之前从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、官网、论坛等业务的运维、运营规划以及架构设计。现任魅族电商团队运维负责人，追崇白猫黑猫论。对架构设计、运营规划、流程标准制定有较深的理解。