转载

宅米网技术变迁——初创互联网公司的技术发展之路

最近几年，互联网创业浪潮风起云涌，各类互联网创业公司如雨后春笋般成立。技术做为互联网创业重要的一个组成部分，也前所未有的受到重视。互联网企业的发展通常都是爆发式增长，在极短的时间内，业务规模、用户量成百上千倍的增长，对网站的技术架构提出极大的挑战。

本文以宅米网为例，跟大家分享在一个典型的互联网创业公司中，技术如何快速响应业务变化，不断重构优化系统架构，满足业务的需求。技术团队又是如何不断地重组优化快速发展壮大，适应业务和技术架构的变化。

一、宅米业务规模变迁

宅米成立于2014年底，是一家专注校园电子商务的互联网企业。仅仅一年多的时间，公司业务覆盖近200座城市，1000多所大中专院校，10000多栋宿舍楼，日均订单20万，峰值订单50万。

相对应的，技术团队规模也从开始创业时的三个工程师，发展成一个50人的团队。公司业务规模变迁如图1。

图1 宅米业务规模变迁

二、宅米技术架构变迁

象所有初创互联网公司一样，宅米早期的系统架构十分简单。四个主要的业务系统：买家系统、卖家系统、供应链系统、运营支撑系统，组成公司的核心应用系统。Nginx做为前端web服务器通过负载均衡服务向移动App及移动Web提供服务。如图2所示。

图2 宅米系统架构1.0

这样一个简单的系统架构在公司早期并没有什么问题，在日均订单只有几千单的时候，系统的处理能力并不是当时最主要的问题。但是随着用户、商品、订单的快速增长，系统的压力越来越大，主要表现是数据库的负载压力特别高，高峰期数据库响应延迟加大。当时公司的业务目标是日均订单20万，峰值订单50万，性能测试的结果是当前的系统架构根本不足以支撑这样的订单量。

解决方案是增加缓存和进行数据库主从分离。在应用服务层增加Redis缓存，缓存业务对象。在前端使用第三方CDN服务，缓存图片、JS等静态文件。并且把数据分析任务迁移到大数据平台以降低数据库的访问压力。重构后的系统如图3所示。

图3 宅米系统架构2.0

2.0版的架构对系统性能和处理能力有极大的提升，但是随着系统越来越复杂，许多功能被重复开发，开发新需求的工期越来越长，Bug也越来越多。于是决定使用分布式服务，将可复用的功能模块以分布式服务的方式独立部署，供各个业务系统使用，从而提高开发效率和维护成本。

同时随着业务规模的不断发展，另一个问题也凸显出来：订单表的数据量急剧增加，按照这样的速度，订单表的单表数据量将很快超过数据库存储的极限。当时考虑的方案有两个，一个是分布式数据库，将订单表拆分到多个物理库中。另一个是冷热分离，将历史订单迁移到MongoDB中，只提供只读查询操作。技术团队经过权衡，最后选择了第二种方案。最新的系统架构如图4所示。

图4 宅米系统架构3.0

三、宅米技术团队变迁

早期宅米技术团队只有三个工程师，几乎没有分工，每个人都是全栈工程师，哪里需要就做什么。随着公司逐渐发展壮大，技术团队的规模也不断变化，当团队有十多个人的时候，就必须要进行组织分工。最初的分组方式是按照工程师的专业职能进行分工，即后端组，app组，前端组。如图5所示，这样分组的好处是相同专业技能的工程师在一个小组，彼此更容易进行技术交流和协作。