魅族电商运维之路

  1. 云栖社区>
  2. 博客>
  3. 正文

魅族电商运维之路

听云 2016-04-10 20:15:13 浏览1767
展开阅读全文

文章出自:听云博客

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

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

  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万的流量,哪一家的流量到我们的商城,用户转化率,订单转化率更高呢?这些都是值得我们去考虑去探索的,这些是技术外的事情。还有一点也值得一说,所说的业务逻辑也就是业务直接的关联性。假设其中一个环节出了了集群卡顿、处理效率低下,我们首先想到的是:这个集群挂了,会不会导致整个业务瘫痪?这个集群挂了?会产生哪些蝴蝶效应?目前正有哪些业务依赖于这个集群?如果这些你都答不上来的话,那么首先赶紧对这个集群做扩容。再好好去分析,这个集群的上游和下游,搞清楚压力来自哪里。我们该怎么杜绝后患,一劳永逸才好。

抢购系统架构:

1122.png 

       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端,代码层,看看都有什么性能方面的问题。如图所示:

11233.jpg

11344.jpg

11566.png

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

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

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

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

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

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

       愿各位的系统,永不宕机!

       原文链接:http://blog.tingyun.com/web/article/detail/397

网友评论

登录后评论
0/500
评论
听云
+ 关注