最近几年，互联网创业浪潮风起云涌，各类互联网创业公司如雨后春笋般成立。技术做为互联网创业重要的一个组成部分，也前所未有的受到重视。互联网企业的发展通常都是爆发式增长，在极短的时间内，业务规模、用户量成百上千倍的增长，对网站的技术架构提出极大的挑战。
本文以宅米网为例，跟大家分享在一个典型的互联网创业公司中，技术如何快速响应业务变化，不断重构优化系统架构，满足业务的需求。技术团队又是如何不断地重组优化快速发展壮大，适应业务和技术架构的变化。
一、宅米业务规模变迁
宅米成立于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所示，这样分组的好处是相同专业技能的工程师在一个小组，彼此更容易进行技术交流和协作。
![图片描述]()
图5 宅米技术团队组织架构1.0
当团队规模较小，只有十几个人，产品也不多，只有一两个产品的时候，这样的组织方式是可以有效运作的。但是当人数有几十个，产品有五六个时候，每个产品都需要跨越多个技术小组进行开发，沟通和协调的成本迅速上升，这时候按产品归属分工更有利提高开发效率，组织架构如图6所示。
![图片描述]()
图6 宅米技术团队组织架构2.0
随着团队规模不断增长，分工也更细致，组织架构也需要做出更精细的调整，如图6所示。
![图片描述]()
图7 宅米技术团队组织架构3.0
技术部成立专门的架构组，进行性能测试、性能优化、架构重构、流程改进等业务无关的技术改造，并对产品研发团队进行技术支持，是技术部的救火队和特种兵。
四、总结
在云计算与互联网技术非常完善的今天，对于大多数初创互联网公司而言，技术几乎不会成为创业的障碍。如果业务模式正确，得到市场的认可和资本的追捧，业务规模迅速发展，即使技术上出现一些差错和滞后，也基本不会对业务发展造成重大伤害。
宅米在自身短暂的发展历程中，快速的业务发展不断对技术提出各种各样的挑战，技术团队也曾手忙脚乱穷于应对，但是通过不断的自我进化，经历一次又一次的脱胎换骨和浴火重生，终究还是成长起来了。
本文转自 www19 51CTO博客，原文链接：http://blog.51cto.com/doujh/1829821，如需转载请自行联系原作者
