宅米网技术变迁——初创互联网公司的技术发展之路
声明：本文来自SDCC 2016数据库&架构峰会（上海站）的嘉宾分享，未经许可禁止任何形式的转载。
作者：李智慧，宅米CTO，曾供职阿里巴巴与英特尔亚太研发中心，从事大型网站、分布式系统、大数据平台方面的研发工作。著有《大型网站技术架构-核心原理与案例分析》一书。。。
责编：钱曙光，关注架构和算法领域，寻求报道或者投稿请发邮件[email protected]，另有「CSDN 高级架构师群」，内有诸多知名互联网公司的大牛架构师，欢迎架构师加微信qshuguang2008申请入群，备注姓名+公司+职位。
最近几年，互联网创业浪潮风起云涌，各类互联网创业公司如雨后春笋般成立。技术做为互联网创业重要的一个组成部分，也前所未有的受到重视。互联网企业的发展通常都是爆发式增长，在极短的时间内，业务规模、用户量成百上千倍的增长，对网站的技术架构提出极大的挑战。
本文以宅米网为例，跟大家分享在一个典型的互联网创业公司中，技术如何快速响应业务变化，不断重构优化系统架构，满足业务的需求。技术团队又是如何不断地重组优化快速发展壮大，适应业务和技术架构的变化。
一、宅米业务规模变迁
宅米成立于2014年底，是一家专注校园电子商务的互联网企业。仅仅一年多的时间，公司业务覆盖近200座城市，1000多所大中专院校，10000多栋宿舍楼，日均订单20万，峰值订单50万。
相对应的，技术团队规模也从开始创业时的三个工程师，发展成一个50人的团队。公司业务规模变迁如图1。
二、宅米技术架构变迁
象所有初创互联网公司一样，宅米早期的系统架构十分简单。四个主要的业务系统：买家系统、卖家系统、供应链系统、运营支撑系统，组成公司的核心应用系统。Nginx做为前端web服务器通过负载均衡服务向移动App及移动Web提供服务。如图2所示。
这样一个简单的系统架构在公司早期并没有什么问题，在日均订单只有几千单的时候，系统的处理能力并不是当时最主要的问题。但是随着用户、商品、订单的快速增长，系统的压力越来越大，主要表现是数据库的负载压力特别高，高峰期数据库响应延迟加大。当时公司的业务目标是日均订单20万，峰值订单50万，性能测试的结果是当前的系统架构根本不足以支撑这样的订单量。
解决方案是增加缓存和进行数据库主从分离。在应用服务层增加Redis缓存，缓存业务对象。在前端使用第三方CDN服务，缓存图片、JS等静态文件。并且把数据分析任务迁移到大数据平台以降低数据库的访问压力。重构后的系统如图3所示。
2.0版的架构对系统性能和处理能力有极大的提升，但是随着系统越来越复杂，许多功能被重复开发，开发新需求的工期越来越长，Bug也越来越多。于是决定使用分布式服务，将可复用的功能模块以分布式服务的方式独立部署，供各个业务系统使用，从而提高开发效率和维护成本。
同时随着业务规模的不断发展，另一个问题也凸显出来：订单表的数据量急剧增加，按照这样的速度，订单表的单表数据量将很快超过数据库存储的极限。当时考虑的方案有两个，一个是分布式数据库，将订单表拆分到多个物理库中。另一个是冷热分离，将历史订单迁移到MongoDB中，只提供只读查询操作。技术团队经过权衡，最后选择了第二种方案。最新的系统架构如图4所示。
三、宅米技术团队变迁
早期宅米技术团队只有三个工程师，几乎没有分工，每个人都是全栈工程师，哪里需要就做什么。随着公司逐渐发展壮大，技术团队的规模也不断变化，当团队有十多个人的时候，就必须要进行组织分工。最初的分组方式是按照工程师的专业职能进行分工，即后端组，app组，前端组。如图5所示，这样分组的好处是相同专业技能的工程师在一个小组，彼此更容易进行技术交流和协作。
当团队规模较小，只有十几个人，产品也不多，只有一两个产品的时候，这样的组织方式是可以有效运作的。但是当人数有几十个，产品有五六个时候，每个产品都需要跨越多个技术小组进行开发，沟通和协调的成本迅速上升，这时候按产品归属分工更有利提高开发效率，组织架构如图6所示。
随着团队规模不断增长，分工也更细致，组织架构也需要做出更精细的调整，如图6所示。
技术部成立专门的架构组，进行性能测试、性能优化、架构重构、流程改进等业务无关的技术改造，并对产品研发团队进行技术支持，是技术部的救火队和特种兵。
四、总结
在云计算与互联网技术非常完善的今天，对于大多数初创互联网公司而言，技术几乎不会成为创业的障碍。如果业务模式正确，得到市场的认可和资本的追捧，业务规模迅速发展，即使技术上出现一些差错和滞后，也基本不会对业务发展造成重大伤害。
宅米在自身短暂的发展历程中，快速的业务发展不断对技术提出各种各样的挑战，技术团队也曾手忙脚乱穷于应对，但是通过不断的自我进化，经历一次又一次的脱胎换骨和浴火重生，终究还是成长起来了。
编辑推荐：架构技术实践系列文章（部分）：
- 宅米网技术变迁——初创互联网公司的技术发展之路
- 分布式系统设计的求生之路
- 魏晓军：React Native实践之携程Moles框架
- 学霸君姜波：耳目一新的在线答疑服务背后的核心技术
- 爱乐奇麦凯臻：在线教育的内容研发和技术的迭代创新
- 长虹李玮：老牌消费电子企业如何拥抱Docker
- 徐汉彬：日请求过亿的Web系统PHP7升级实践
- 窦威：AcFun的视频架构演化实践
- 傅鸿城：QQ亿级日活跃业务后台核心技术揭秘
- 宁峰峰：尖峰日96万订单，59校园狂欢节技术架构剖析
- 梁阳鹤：每秒处理10万订单乐视集团支付架构
- 沈辉煌：亿级日PV的魅族云同步的核心协议与架构实践
- 李任：携程Docker最佳实践
- 王海军：游戏研发与运营环境Docker化
- 史海峰：当当网高可用架构之道
- 黄哲铿：应对电商大促峰值的九个方法
- 1号店交易系统架构如何向「高并发高可用」演进
- 京东闫国旗：从C10K到C10M高性能网络的探索与实践
- 李林锋：服务化架构的演进与实践
- 1号店架构师王富平：一号店用户画像系统实践
- 唯品会官华：实现电商平台从业务到架构的治理体系
- 沈剑：58同城数据库架构最佳实践
- 荔枝FM架构师刘耀华：异地多活IDC机房架构
- UPYUN的云CDN技术架构演进之路
- 初页CTO丁乐：分布式以后还能敏捷吗？
- 陈科：河狸家运维系统监控系统的实现方案
- 途牛谭俊青：多数据中心状态同步&两地三中心的理论
- 云运维的启示与架构设计
- 魅族多机房部署方案
- 艺龙十万级服务器监控系统开发的架构和心得
- 京东商品详情页应对“双11”大流量的技术实践
- 架构师于小波：魅族实时消息推送架构