魅族电商运维之路

原文出自【听云技术博客】：http://blog.tingyun.com/web/article/detail/397

 

       电商行业飞速发展，电商事故络绎不绝，但还是有不少人热衷于电商行业，投身于电商行业。

       今天我们就围绕魅族电商运维这一块的内容，来做以下四大块的分享：

1. 业务背景

2. 抢购系统架构

3. 一次大型活动需要准备什么

4. 迅速发展的电商业务带来的思考

       

在分享之前我还想给大家看一组数据：

08年魅族电商平台上线

12年9月第二次改版，MX2在商城平台首发

13年9月MX3预订数过百万

14年6月商城抢购PV过亿

14年9月MX4发布预约用户数过千万

15年初注册用户数过二千万

15年6月魅蓝note2抢购当天PV过三亿

15年完成2000万台魅族手机销售量

       由此可见，魅族的电商也是在飞速发展中。

业务背景：

       为什么要分享这个跟技术无关的内容呢？在我看来，如果一个业务运维对自己手里的业务不是特别了解的话，就算技术再好，也只是一介莽夫。就像一个医生，他不能对身体的整个运行状态有一个了解的话，那么你可能看到的是感冒，实际上感冒是由肺热引起的，我们永远不能药到病除，不能找到根源问题，下次还会出现同样的问题。

• 多渠道

           官网、天猫、京东、苏宁、微信……

• 运营活动

           抢购、优惠券、M码、0元秒杀…….

• 流量导入

           QQ空间、微博、微信、百度……

• 业务逻辑

           ……

    这几点，我们主要看运营活动与流量导入。执行一次营销活动，我们要考虑的是，流量从哪里来？来多少？营销活动是哪一类？优惠活动还是0元秒杀？等等......

    例如一次0元秒杀活动和优惠券活动，同样都是从微博导了500万用户过来的话，相比之下，当然是0元秒杀活动的流量更大，转化率也更大。这些经验，都是在很多次活动总结下来的，包括流量来源。例如我们同样是导500万的流量，哪一家的流量到我们的商城，用户转化率，订单转化率更高呢？这些都是值得我们去考虑去探索的，这些是技术外的事情。还有一点也值得一说，所说的业务逻辑也就是业务直接的关联性。假设其中一个环节出了了集群卡顿、处理效率低下，我们首先想到的是：这个集群挂了，会不会导致整个业务瘫痪？这个集群挂了？会产生哪些蝴蝶效应？目前正有哪些业务依赖于这个集群？如果这些你都答不上来的话，那么首先赶紧对这个集群做扩容。再好好去分析，这个集群的上游和下游，搞清楚压力来自哪里。我们该怎么杜绝后患，一劳永逸才好。

抢购系统架构：

 

       1、DNS采用的是DNSPOD智能分流，采用了组合式的分流措施。

           地区+运营商+地区运营商的模式

       2、SLB的RS，为集群单独所有。集群互不影响。每个集群按照上面DNS的解析方式去解析

       3、后端的Redis为主从模式，数据是直接写到Redis，数据不落地。Proxy做分发，每组Proxy互为主备。Php通过算法来对Redis进行读或写。

       前面三点，是我们能看到的技术层面的东西。那我们架构这么搭建，就一定能做一个好的抢购架构吗？当时不是，我们要考虑三点：高可用、高扩展以及我们的高性能。高可用和高扩展，在集群中都已经体现了，我们没有单点故障，有可容错性，有灾备，有Openresty做流量清洗、过载保护等等。那么高性能我们是怎么做的呢？

       我们之前也自己做过性能优化，对架构，对代码等等。架构方面还好，定好的不会轻易去改变。那么代码是实时在产生，SQL也是实时在产生，我们如何去监控这些性能，以及如何优化呢？那我们就招人做吧。在招人的过程中，也面临了很多问题，现在性能优化的人才稀缺，能力参差不齐，我们放弃了自己招人自己去做的想法，因为就算招到了人，能不能做好？要花多久时间才能做好？考虑下来，我们决定外包！做APM的产商五花八门，国内的国外的都有，各有噱头。筛选的过程就不详说了，最后我们选择的是听云APM。

 

       听云APM优点很多，我特别看中的是：

       1、监控内容丰富且详细

       2、优秀及时的售后服务。现在使用半年下来，我们商城的整体效率提高了至少20%，且很好的降低了bug率和系统故障率。把擅长的事情做好，不擅长的事情我们外包给第三方去做，不仅省下人力成本也解决公司HC的问题。

 

       一次大型活动需要准备什么

• 实战演练+压测

• 数据监控

• 数据汇总与分析

• 性能优化

       

       首先一定要经过压测。那么压测的量怎么算呢？那么就根据咱们上文说的，根据活动类型和流量来源去算出大概的量，我们再乘以2倍去做压测。

        在压测的过程中，我们需要利用到听云的APM，一边压测我们一边看监控，MYSQL端，Redis端，代码层，看看都有什么性能方面的问题。如图所示：

       由于数据隐秘性，没有展示详细的性能数据。但是大家还是能看的出来，性能方面的种种问题，其实最好用的是关键应用过程。我们将核心功能的过程输入到监控里面去，展示的数据更为精细和完整。我们自己做完一系列优化后，最后还可以call我们的听云工程师来提供更为专业的帮助。那么这是一个过程，压测 -》 数据监控 –》 数据汇总与分析 – 》性能优化。也是一个循环，我们可以一直去做压测，直到压到我们满意为止。压测可以辛苦我们自己的测试工程师，也可以利用听云Network功能来模拟交易过程，并制定用户数，也能达到压测的目的。OK，那么压测通过之后，即将要到来的大型活动，你还怕吗

       迅速发展的电商带来的思考：

       我们的架构其实做到现在，仍有很多需要完善的地方。我们也经历了很多事故，一次一次的吸取经验，再多点思考，再慢慢调优，很多日日夜夜。

       其实从上文就能看到很多思考的内容。

       系统中有没有单点故障？能不能有很好的容错性？一个集群挂了会不会导致整个交易链路瘫痪（电商系统最重要的就是保证交易链路通畅）？大流量来了我能不能及时去对我的集群扩容？流量清洗、用户、黄牛的控制有没有保证？一千万的服务器，我有没有发挥该有的效率，性能指标能不能达标？

       这是一条漫长的探索之路，业务不同，架构不同，所面临的难处也会有所不同。需要我们自己内部优化，也需要及时的借助外力来完善我们的系统。世上无难事只怕有心人。

       愿各位的系统，永不宕机！