靠谱 的软件外包伙伴

您的位置:首页 > 新闻动态 > 校园O2O平台软件系统架构设计案例分析!

校园O2O平台软件系统架构设计案例分析!

2016-05-18 13:58:15

59store是一家专注校园市场的互联网企业,以校园消费类O2O及金融作为核心业务,自成立以为每年都会举办一次59校园狂欢节,在2016年5月9号的59校园狂欢节创下了单日96万订单,近3500万交易额。其中,59store所面临挑战是:在线服务是否能抵抗住零点疯狂流量的涌入,各个业务线都有活动需求需要按时交付,各项基础服务和众多业务应用的高可用保障,保护第三方合作方的服务器不被59带去的巨大流量压垮……本文将详细解读59store在挑战面前所作的准备,以及其中关键技术架构剖析。

一、面向服务架构

59store定位校园生活服务平台,构建了丰富的消费场景,满足了校园生活多方面的需求。

图片描述

 

图1 项目历程

 

2014年年底,59创造性地推出了“夜猫店”的全新商业模式。2015年下半年,随着生活服务平台理念的深化,59先后推出了饮品店、零食盒、创客中心、外卖等项目,并且针对校园金融推出了白花花、白借借等金融业务。2016年开始,以信用钱包为核心,升级并扩充了若干新的金融类业务。随着上云印店、社区的先后推出,一个校园生活服务平台雏形初现。

在早期开发夜猫店、饮品店、零食盒的过程中,我们看重敏捷开发,快速迭代,小步快跑,不断试错,以至于没有充分地考虑系统抽象,做了很多重复业务特征的实现,缺少复用和整合。随着业务平台化趋势的凸显,抽象而可持续的业务架构迫在眉睫。经过半年的不断抽象、剥离、重构,现在59已经形成了一整套基础服务体系,以及构建在其之上的众多业务。

图片描述

 

图2 服务-应用

 

在备战今年59校园狂欢节的过程中,我们不仅要应对巨大的访问流量,而且还有新的项目和活动需要上线(代号为folivora的秒杀系统和代号为paramecium的品牌馆)。得益于成熟稳定的基础服务,我们可以非常快速地构建上层应用,而忽略底层数据结构和服务接口的创建,让开发、维护变得轻松而愉悦。在基础服务不断演进成熟的过程中,我们总结出了以下几点感受。

1. 明确标准

一个制定良好的数据结构和服务接口,会让往后的开发、维护省去很多的潜在成本,包括但不限于常用单词的全局统一含义、变量命名标准,接口风格统一等等。没有这些统一的规范就好比脚底有沙子,走得越远,脚会被磨得越破。

2. 接口细粒度

接口定义到怎么样的细粒度,会直接影响使用者的效率。仅仅提供增删改查的操作,或每一个功能都配备特定的接口,都会比较偏颇。在不断摸索的过程中,59逐步统一了“原子业务化”的接口设计思想,即接口需要恰如其分地描述一个独立的原子业务。比如create_order即生成一个订单,包括了订单金额,折扣,促销,订单状态,相关时间,用户信息,订单信息,商品明细等一系列逻辑。cancel_order取消一个订单,包括了状态异常的判断,不同支付方式退款,优惠券、积分的处理等。

3. 划清职责

基础服务层需要服务众多业务,而不同的业务各有特点,如果基础服务支持所有业务的个性特点,势必会导致服务层数据结构的冗余和潜在的不稳定因素。因此我们严格划分服务和应用的交付界限,服务仅仅提供所有业务场景通用的数据结构和接口,比如订单状态,用户头像,商品名称等。简单的个性化业务需求,可以使用服务层数据结构包含的一个业务自定义JSON字段来满足需求。更复杂的业务个性信息则需要业务系统自身来维护,比如某个打印订单文件空白页检测结果信息等。在明确职责的基础上提供一定程度的灵活性,不断沉淀出稳定的基础服务。

二、秒杀系统

5月7号开始,59会发起一系列的秒杀活动来预热59校园狂欢节,然后在5月9号达到活动高潮。对此,我们做了一系列的技术优化方案来保障秒杀业务的服务可用。

秒杀是一个读多写少的场景,并且瞬时下单的系统负载大,对数据的一致性要求比较高。针对这样的业务特点,我们对获取数据接口和下单接口做了不同的优化方案。

获取数据接口方面,秒杀商品信息全部缓存在Redis集群中,以减缓高并发场景下的系统压力和数据库负载。

秒杀下单接口的瞬时访问量大,对数据的一致性要求高,因此我们做了特殊的设计。假设一个商品秒杀库存有5件,库存的信息会被存储在一个Redis集群中,并且留有一定冗余,比如记录秒杀商品库存为8件。多台秒杀计算节点分布式部署,使得其可以线性水平扩展,保障高可用,不会成为性能瓶颈。下单请求会被分发到任意一台服务器,然后检测当前秒杀商品是否已秒完,如果是,则直接返回已秒完,如果不是,则直接调用订单服务接口下单。由于我们放入了比实际秒杀库存更多的请求进来,所以在下单过程中如果发现秒杀商品无库存,同样会给用户报出已秒完。

图片描述

 

图3 秒杀系统架构

 

针对秒杀应用,行业的惯用做法是使用队列来削峰,从而减缓系统负载。不过经过团队讨论,我们决定简化系统设计为如上叙述。主要有以下几个方面的考虑:1、系统可以在秒杀下单逻辑一开始便判断业务逻辑是否需要继续(即是否已秒完),如果已秒完则立即返回,不继续后续业务逻辑执行,这隐含地做了“削峰”的工作。并且系统结构比使用消息队列的方案更简单。消息队列方案至少包含一个消息队列存储秒杀请求,生产者、消费者的逻辑实现,以及商品被秒杀完后,消息队列中请求的处理和后续到来请求的处理逻辑等。2、调用下单模块没有使用队列来“削峰”,因为业务决定我们每场秒杀的商品库存不多,数据库可以承受得起这样的并发量。

三、数据库拆分

在推进服务化架构之前,59所有的数据库表都集中在同一个数据库实例中。随着业务的飞速增长,数据库承受了非常大的压力,瓶颈效应凸显。于是在服务化一开始,我们便做了分库优化。

首先是拆:针对业务特点,将独立的业务模块逐步抽离,比如数据统计,APP支持,活动模块等。并且新上线的项目会严格把控存储位置和依赖关系,能独立的数据库表便不放在主库中。其次是合:基础订单服务,商品服务等使用的分布式数据库独立部署。

在构建分布式数据库的过程中,我们选用mycat作为数据库拆分中间件,它可以提供良好的针对分片规则的数据库拆分服务。对于商品服务而言,几乎所有的场景(不管是卖家管理自己商品,或者买家浏览店铺商品),都需要通过卖家ID获得商品列表。所以以商品owner_id作为分片规则水平拆分,即可以满足需求。关于订单服务,常见业务场景不仅包括买家通过买家ID获取自己的订单列表,也包括卖家通过卖家ID获取自己的订单列表。因此从任何一个维度划分都不能满足另一方的需求。针对这个问题,59的解决方案如下。

图片描述

 

图4 数据库拆分

 

我们定义了买家库和卖家库,两者通过MySQL的binlog机制保持数据同步。买家库表定义了一个sharding字段作为分片规则,被划分成了32个分片。sharding是用户ID的后若干位,从而在买家库,通过用户ID的订单检索可以非常方便地使用到分片规则,提升检索性能。卖家库我们暂时没有做水平拆分,而是一个数据库实例。在卖家ID上建立索引,从而在卖家库通过卖家ID获取订单列表同样可以有不错的性能表现。买家库没有在卖家ID建立索引,同步机制仅仅同步数据,而不同步结构。卖家库是一个只读实例,当卖家需要修改一个订单信息的时候,需要在买家库进行操作。如何在已知订单ID的情况下,检索订单的请求可以使用到买家库的分片规则便成为最后一个问题。我们的解决方案是:订单ID中包含了sharding信息,从而在修改一个订单信息的时候可以轻松应用到分片规则。

当订单数据量非常庞大的时候,冷数据归档会带来很大的性能提升。结合校园市场特点,用户4年一个大周期,1学期一个小周期,以每一学期作为时间节点来归档冷数据会带来最佳的用户体验。

四、最后

在59store的技术成长历程中,任何的技术选型、技术方案、技术优化都是业务来驱动的。从最开始的一个单独的PHP应用,到现在60多个服务、应用,从最开始的一台VPS,到现在数百台云服务器,技术始终在59的发展历程中扮演着至关重要的作用。不同的阶段,技术的主要矛盾点是不同的,如何准确的拿捏和把握,值得每一个创业的技术人揣摩和体会。

 

 

关于:中科研拓

深圳市中科研拓科技有限公司专注提供软件外包、app开发、智能硬件开发、O2O电商平台、手机应用程序、大数据系统、物联网项目等开发外包服务,十年研发经验,上百成功案例,中科院软件外包合作企业。通过IT技术实现创造客户和社会的价值,致力于为用户提供最佳的软件解决方案。联系电话400-0316-532,邮箱sales@zhongkerd.com,网址www.zhongkerd.com


  上一篇   [返回首页] [打印] [返回上页]   下一篇