写点什么

宅米网技术架构演进分析

用户头像
andy
关注
发布于: 2021 年 01 月 29 日
宅米网技术架构演进分析

宅米网,曾经爆红的互联网创业项目,经历过高增长的时期。但是,市场变化就像女人处于大姨妈的时候一样,捉摸不定。创业维艰,一点也不假。无论你多么风光美丽,都要心怀感恩之心,要有敬畏之心,因为,你永远不知道下一刻,你的企业将何去何从。当然,对于一群 90 后创业者而言,经历的一切,将会是极其宝贵的财富。


为什么要谈论宅米网,实际上,还是为了做好架构演进分析,提升架构设计与技术选型方案能力。宅米网作为一个创业项目,在较短时间内获得了快速的用户增长,这对于今天许多的新兴互联网创业项目而言,如何设计高性能架构,如何提升和改进系统性能,如何保证高可用,都是具有一定借鉴意义的。


一、宅米网简介


宅米网成立于 2014 年,一群 90 后怀揣创业梦想,发现了校园商机,将“寝室便利店”业务模式,运用到了校园之上。简而言之,就是店主是在校学生,然后采购囤积货物于寝室之中,将寝室作为仓储,并将商品信息发布于平台之上。用户,也是在校学生,则登录平台,查阅商品,进而实施下单购买行为。


商品通常都是在校学生日常的消费用品,包括零食、面包、方便面、洗漱用品等等。从下单到送货上门大概十几分钟,甚至更快。因为可能店主与客户同处于同一栋寝室,或者同处于同一层寝室楼,大家相距很近。这样的模式,被称为迷你版的“淘宝+京东”模式。


二、技术架构 1.0


宅米网系统上线,整个架构实际上与大多数互联网创业项目一样,怎么简单,怎么来。这是由互联网特点决定的。互联网的一大特点就是变化快。那么,对于任何项目而言,是没有办法像建筑等行业那样,设计一次,便能够永久使用。


创业初期阶段的主要目的就是吸引用户,验证商业模式的可行性,快速构建简单的系统架构。无论是业务的复杂性,还是用户的规模性,都还不是主要问题,不会对整体系统造成极大压力。在上线系统之后,宅米网的并发量大约在两三千单左右,整个系统运行良好。


系统技术架构 1.0 的部署图如下:



从部署图可以看出,用户主要通过 APP 和网页访问系统。系统使用负载均衡分摊用户请求,构建两层负载均衡。我们知道 Ngxin 支撑并发数量级在上万级别,那么,再上一层,则是能够支撑十万级别并发量的软件负载均衡。为什么不用硬件负载均衡 F5?因为处于创业初期,用户规模还不够大,并发量也不可能达到百万级别。同时,F5 需要花费极高的费用,成本太高。


数据库使用单机 MySql,应用服务器则构建系统集群,也就是水平伸缩方式,增加应用系统服务器。当请求量不断增长时,遇到了应用系统的瓶颈,就直接暴力增加服务器即可。


随着业务的推广,不断验证商业模式是具有可行性的,是具有市场前景的。因此,宅米网迎来了各种风险投资,获得资金支持。从用户消费的情况来看,大多集中于晚上 9 点到 11 点,这段时间对于系统的压力极大。同时,伴随初期业务的成功,用户的规模也在快速增长。系统架构的一些问题也暴露出来了。


第一,系统的业务处理时间变慢,响应时间加长,当订单量达到一万以上,出现订单延时,严重的话,还导致系统奔溃;


第二,数据库的压力陡增,所有业务处理的请求,最终的压力都会落到数据库之上,这样导致系统进一步变慢;


第三,预计未来将要迎来更高一级的用户并发量,达到 50 万级别,这是运营推广所带来的结果。那么,当前系统就无法支持未来用户的高并发请求,需要对系统进行升级。


任何项目,都会经历推广运营阶段,用户量大量增加,如何抗住这样的压力,这是需要提前做好准备的。


三、技术架构 2.0


正是基于以上挑战,宅米网进行了架构升级改造。就像架构 1.0 所面临的问题那样,所有的请求压力都落在了数据库之上,那么,解决这个问题,就是将单机 MySql,进行读写分离,构建一主多从,主机负责数据的更新的操作,从机负责数据的查询操作。保证数据一致性,主机进行同步复制。


任何电商业务,用户的请求所包含的读操作永远要大于写操作。为了降低数据的访问压力,提高系统性能,宅米网做了大量的数据缓存处理。


构建 Redis 集群,将大量的店铺信息、商品信息存储于分布式缓存之中。这些数据,商家一旦配置发布,是不会经常进行修改的。存储于缓存之中,也避免用户大量的读操作落到数据库之上。对于用于展示的商品数据,图片也是一个重要的组成部分,为了进行图片存储,购买了分布式文件系统,将原来存储于应用服务器之上的图片迁移出来。让应用服务器更加专注于业务处理。


用户大量的请求,主要是读操作,那么,静态的页面和文件,就可以缓存起来,便于最为快捷的响应用户。采取了动静分离,动态请求依然交由业务服务器处理,静态数据则通过缓存直接返回。宅米网为了更快响应用户请求,使用了 CDN 服务器,用于存储大量的静态图片和文件,如 js、html、css 等。同时,我们也知道,Nginx 既能够实现负载均衡,也能够作为反向代理服务器。到达 Nginx 的请求,依然会去查找缓存,如果具有用户访问的静态数据,则直接返回,如果没有,则再请求应用服务器。


这里需要补充一点,由于购买的是第三方的文件系统服务。该该服务还包含了 CDN 服务,故整个系统的升级工作,只需要将原有的文件存储路径变为分布式文件系统就行了,其他的地方,不需要做任何变动。这样对于系统的影响不大,稳定性很高。


互联网项目为了能够更加精准地分析和满足用户需求,需要通过数据进行分析和挖掘。同时,整个运营活动的效果,用户的购买行为和习惯,都需要通过数据进行分析处理。于是,宅米网引进了大数据平台技术,利用数据服务业务发展。为了进行数据的获取和监控,采用异步消息组件 Kafka,将数据传输至大数据平台,用户数据分析。


之前说到,MySql 采用了一主多从,从机中的其中一台专门用于应用服务进行读操作。对于一些用户的读取操作行为,是没有办法真正保证只是从缓存中获取。比如,当缓存数据失效,那么,依然需要去访问数据,获取实时正确的数据。从机的另外一台便可以专门用于大数据平台的数据来源,不同的从机做不同的事情,这样可能使得数据库得到最大的利用。


技术架构 2.0 的部署图如下:



随着发展,系统 2.0 架构也遇到了新的挑战。


第一,数据库存储的容量终究要达到极限,预计未来系统的并发量峰值将达到 200 万,而 Mysql 容量只是千万级别;


第二,由于业务快速发展,创业发展阶段的需求,都是进行非常快速的实现,也就是直接功能堆积,并没有做各种设计、优化、架构等工作,导致业务复杂度非常高。同时,代码之间的耦合性和重复性,也非常高。这就使得系统后续的开发速度大大降低,到了开发无法及时响应业务需求的时候。


四、技术架构 3.0


为了解决架构 2.0 面临的代码重复、耦合程度高等问题,宅米网进行了业务拆分,开始了微服务化过程。将系统中耦合程度高,复用性大的功能模块提取出来,构建服务集群,通过微服务的远程调用,实现业务处理。微服务框架主要使用当时流行的 Dubbo 框架。


基于“寝室便利店”模式,用户消费支付的订单,活跃时间大约十多分钟,之后的订单数据主要是用于查看,不会再有任何修改行为。这里可能会提出疑问,商品使用之后,不符合,不是需要进行退换货流程吗?实际上,鉴于商家与用户的关系,两者相距很近,同时,又都是学生。商品不符合,直接就可以通过线下自行解决,完全没有必要再弄一套退换货线上流程。这样反而大大提升了问题的解决速度。并不是什么东西都要搬到线上才能够解决。还是需要实事求是的看待问题。


既然订单的活跃时间较短,那么,可以进行冷热分离。热订单,就是还未结束流程的订单以及结束时间还不是很长的订单。其他的订单,都归类于冷订单。数据库的写操作,主要针对的是热订单,热订单数据依然存储于 MySql 之中。结束时间超过一个月的冷订单,则可以进行数据迁移,迁移至 MongDB 之中。这一招,实际上电信运营商就经常使用,大量的用户通过记录,实际上都是存储到 MongDB 之中,而不是数据库之中。


系统增加批处理任务,也就是定时任务,定期扫描数据库中的冷数据,然后,将数据迁移出去。


以下是技术架构 3.0 的架构图:



五、总结


在整个系统演进的过程中,所有采用的技术决策,都是基于真实面临的具体场景,针对提供的各个技术方案,分析方案的优点有哪些,方案的缺点又有哪些,优点是否满足业务需要和解决问题,缺点是否可以容忍。


业务驱动技术,技术服务业务。技术具有自身的强大能力,但也需要结合实际场景,实事求是,因地制宜。我们既要保证当前系统稳定可靠,支持高并发高性能。也要做好准备,为即将面临的下一个阶段问题,提出有效的应对方案。


软件架构就是一个渐进式发展的过程,系统是不断迭代出来的,而不是设计出来的。


虽然宅米网之后的发展不是很好,但是依然不影响我们将其作为一个创业项目的案例,去研究和分析,不要以为别人遇到的问题,自己不会碰到。我们都不是天才,不可能什么都行,别人掉入的坑,我们有可能还会遇到。所以,抱着谦卑和包容的心态,去努力进步就好。


用户头像

andy

关注

还未添加个人签名 2019.11.21 加入

还未添加个人简介

评论

发布
暂无评论
宅米网技术架构演进分析