许多电商平台都会经历相似的过程:流量和业绩每年以几倍至十几倍的速度增长;瞬间访问量可能是平时的几十倍;网络带宽被占满,用户响应很慢;机器负载高甚至宕机;数据库压力过大导致服务不可用……
大数据技术的发展引发众多电商架构师思考,在面对用户蜂拥而至这件好事,如何在海量数据处理中实时发现有效信息,为构建稳定高效的系统架构设计提供指导。在【WOT2015"互联网+"时代大数据技术峰会】 现场,魅族电商平台高级架构师何岳娟就魅族电商平台架构变迁之路的经验和体会和大家进行交流。
何岳娟告诉记者,魅族电商架构分为四个层级:
业务层:第三方天猫,京东,苏宁与官网的商城及APP;
业务服务层:交易,新品发布,手机导购,推荐服务为各平台提供营销策略;
基础服务层:订单,用户,支付,库存,图片等为业务服务与营销层提供基本的服务点;
据层存储层:MySQL, NoSQL, MQ , HBase以及一些分布式文件系统
基于这四个层级产生的数据建立分析平台, 对用户行为用户需求进行分析。
随着魅族近两年的发展,用户对其电商平台的关注度越来越高,用户增长速度非常快。在享受这种进步的同时,平台性能也在经历严峻考验。谈及贯穿平台架构变迁之路的指导思想,何岳娟将提升高可用、高并发、容灾性三个能力的提升视为核心,来实现对网站稳定性能的保障。抢购场景中LVS崩溃、DDoS攻击、刷单带来的高并发以及抢购时服务器如何实现快速扩容等,都是在业务高速发展下迫切需要解决的问题。
在针对这些问题进行平台架构变迁的过程中,何岳娟和魅族技术团队曾经也走过许多弯路。比如说之前用GLSB、OSPF、智能DS分发解决数据容灾问题。但采用OSPF时,要对整个机房交换部署模式进行变造,影响非常大。而且,OSPF也并不能很好地解决魅族电商平台高并发故障迁移的问题。
这是因为在遭遇高并发时,LS、分发服务器不保证不会崩溃,一旦崩溃,转给其他的分发服务器,其他的分发服务器也不具备承受能力。魅族后来直接放弃了这个方案,结合业务需求和自身能力,改为族采用放弃一部分用户然后采用活动能正常的进行下去来做LS断点的问题。
新方案的优势在于,当一个机房的LS宕或是群宕掉时,可以自动切换到其他机房。何岳娟秀露,魅族计划采用GLSB,进行大LS的方案解决以后更高并发的模式以及以后跨机房容灾的问题。
对于“黄牛”这个世界性难题,魅族在最开始把只它看成功能性防御。但实际上,这种数据请求的模式极有可能出现伪造数据。因此,魅族通过对用户行为数据分析构建了信用分值评估系统,如果用户行为数据是伪造数据的话,在进行分析时可以看到,这些数据非常“死板”。
所谓“死板”,就是说黄牛一般只会注册一个帐户,而不会关注魅族官网,在网站只留下非常有限的行为信息,可以将具有这种特点的用户看作是是死点用户。而如果是在整个官网体系里比较活跃的用户,系统会将他评为优质用户。
一般来讲,面对评级较低的用户,系统在做防杀时会有一些“误伤”的现象。为了避免一些评级较低的用户无法正常方问,在做防杀的时候,魅族不会没有把所有的数据全部“干死”,而是将自有数据与第三方数据进行交换,引入第三方的数据评级,对两者数据分析结果进行对比之后再进行防御。
何岳娟表示,跨机房容灾和跨机房的数据同步问题,仍然是魅族在未来一段时间内关注的重点。魅族在这些方面一直在努力,比如在魅族有一个OKR评级功能,这个评级会根据业务故障时间来评级。这种互联网评级模式不可能做到不产生故障,但可以尽量减少故障产品的产生。
对于技术和工具的选型,何岳娟的建议在选用新功能前,一定要对性能进行前期测试。一旦产生问题,通过测试可以及时暴露出来,引导我们寻找解决方案。对于实在解决不了的问题,魅族会选择直接放弃这种模式,而在上线采用第三方服务。当然,还是要注意对服务进行大规模、全方位的测试,来避免之后突发情况下的措手不及。
小编精心为大家挑选了近日最受欢迎的几篇热文:
回复001,看丁俊的《【重磅干货】看了此文,Oracle SQL优化文章不必再看!》;
回复002,看《灾备故障上了红头文件,容灾技术到底哪家强?》;
回复003,看吕海波的《去不去O,谁说了算?》;
回复004,看胡怡文《PG,一道横跨oltp到olap的梦想之桥》;
回复005,看付新《达梦专家解读:国产数据库也疯狂》;
回复006,看郭耀龙《假事务之名,深入研究UNDO与REDO》;
回复007,看宋日杰《Oracle后台专家解决library cache锁争用的终极武器》;
回复008,看周俊《被埋没的SQL优化利器——Oracle SQL monitor》。
如果字段的最大可能长度超过255字节,那么长度值可能…
只能说作者太用心了,优秀
感谢详解
一般干个7-8年(即30岁左右),能做到年入40w-50w;有…
230721