宅米网技术架构演进分析

宅米网，曾经爆红的互联网创业项目，经历过高增长的时期。但是，市场变化就像女人处于大姨妈的时候一样，捉摸不定。创业维艰，一点也不假。无论你多么风光美丽，都要心怀感恩之心，要有敬畏之心，因为，你永远不知道下一刻，你的企业将何去何从。当然，对于一群 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 的架构图：

五、总结

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

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

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

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