宅米网技术变迁——初创互联网公司的技术发展之路
2017-01-23 14:48
1011 查看
声明:本文来自SDCC 2016数据库&架构峰会(上海站)的嘉宾分享,未经许可禁止任何形式的转载。
作者:李智慧,宅米CTO,曾供职阿里巴巴与英特尔亚太研发中心,从事大型网站、分布式系统、大数据平台方面的研发工作。著有《大型网站技术架构-核心原理与案例分析》一书。
责编:钱曙光,关注架构和算法领域,寻求报道或者投稿请发邮件qianshg@csdn.net,另有「CSDN 高级架构师群」,内有诸多知名互联网公司的大牛架构师,欢迎架构师加微信qshuguang2008申请入群,备注姓名+公司+职位。
最近几年,互联网创业浪潮风起云涌,各类互联网创业公司如雨后春笋般成立。技术做为互联网创业重要的一个组成部分,也前所未有的受到重视。互联网企业的发展通常都是爆发式增长,在极短的时间内,业务规模、用户量成百上千倍的增长,对网站的技术架构提出极大的挑战。
本文以宅米网为例,跟大家分享在一个典型的互联网创业公司中,技术如何快速响应业务变化,不断重构优化系统架构,满足业务的需求。技术团队又是如何不断地重组优化快速发展壮大,适应业务和技术架构的变化。
相对应的,技术团队规模也从开始创业时的三个工程师,发展成一个50人的团队。公司业务规模变迁如图1。
![](https://img-blog.csdn.net/20160629085343576)
图1 宅米业务规模变迁
![](https://img-blog.csdn.net/20160629085421577)
图2 宅米系统架构1.0
这样一个简单的系统架构在公司早期并没有什么问题,在日均订单只有几千单的时候,系统的处理能力并不是当时最主要的问题。但是随着用户、商品、订单的快速增长,系统的压力越来越大,主要表现是数据库的负载压力特别高,高峰期数据库响应延迟加大。当时公司的业务目标是日均订单20万,峰值订单50万,性能测试的结果是当前的系统架构根本不足以支撑这样的订单量。
解决方案是增加缓存和进行数据库主从分离。在应用服务层增加Redis缓存,缓存业务对象。在前端使用第三方CDN服务,缓存图片、JS等静态文件。并且把数据分析任务迁移到大数据平台以降低数据库的访问压力。重构后的系统如图3所示。
![](https://img-blog.csdn.net/20160629085449187)
图3 宅米系统架构2.0
2.0版的架构对系统性能和处理能力有极大的提升,但是随着系统越来越复杂,许多功能被重复开发,开发新需求的工期越来越长,Bug也越来越多。于是决定使用分布式服务,将可复用的功能模块以分布式服务的方式独立部署,供各个业务系统使用,从而提高开发效率和维护成本。
同时随着业务规模的不断发展,另一个问题也凸显出来:订单表的数据量急剧增加,按照这样的速度,订单表的单表数据量将很快超过数据库存储的极限。当时考虑的方案有两个,一个是分布式数据库,将订单表拆分到多个物理库中。另一个是冷热分离,将历史订单迁移到MongoDB中,只提供只读查询操作。技术团队经过权衡,最后选择了第二种方案。最新的系统架构如图4所示。
![](https://img-blog.csdn.net/20160629085516515)
图4 宅米系统架构3.0
![](https://img-blog.csdn.net/20160629085546110)
图5 宅米技术团队组织架构1.0
当团队规模较小,只有十几个人,产品也不多,只有一两个产品的时候,这样的组织方式是可以有效运作的。但是当人数有几十个,产品有五六个时候,每个产品都需要跨越多个技术小组进行开发,沟通和协调的成本迅速上升,这时候按产品归属分工更有利提高开发效率,组织架构如图6所示。
![](https://img-blog.csdn.net/20160629085609281)
图6 宅米技术团队组织架构2.0
随着团队规模不断增长,分工也更细致,组织架构也需要做出更精细的调整,如图6所示。
![](https://img-blog.csdn.net/20160629085628173)
图7 宅米技术团队组织架构3.0
技术部成立专门的架构组,进行性能测试、性能优化、架构重构、流程改进等业务无关的技术改造,并对产品研发团队进行技术支持,是技术部的救火队和特种兵。
宅米在自身短暂的发展历程中,快速的业务发展不断对技术提出各种各样的挑战,技术团队也曾手忙脚乱穷于应对,但是通过不断的自我进化,经历一次又一次的脱胎换骨和浴火重生,终究还是成长起来了。
李智慧:宅米网技术变迁——初创互联网公司的技术发展之路
陶文质:分布式系统设计的求生之路
魏晓军: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”大流量的技术实践
架构师于小波:魅族实时消息推送架构
作者:李智慧,宅米CTO,曾供职阿里巴巴与英特尔亚太研发中心,从事大型网站、分布式系统、大数据平台方面的研发工作。著有《大型网站技术架构-核心原理与案例分析》一书。
责编:钱曙光,关注架构和算法领域,寻求报道或者投稿请发邮件qianshg@csdn.net,另有「CSDN 高级架构师群」,内有诸多知名互联网公司的大牛架构师,欢迎架构师加微信qshuguang2008申请入群,备注姓名+公司+职位。
最近几年,互联网创业浪潮风起云涌,各类互联网创业公司如雨后春笋般成立。技术做为互联网创业重要的一个组成部分,也前所未有的受到重视。互联网企业的发展通常都是爆发式增长,在极短的时间内,业务规模、用户量成百上千倍的增长,对网站的技术架构提出极大的挑战。
本文以宅米网为例,跟大家分享在一个典型的互联网创业公司中,技术如何快速响应业务变化,不断重构优化系统架构,满足业务的需求。技术团队又是如何不断地重组优化快速发展壮大,适应业务和技术架构的变化。
一、宅米业务规模变迁
宅米成立于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
技术部成立专门的架构组,进行性能测试、性能优化、架构重构、流程改进等业务无关的技术改造,并对产品研发团队进行技术支持,是技术部的救火队和特种兵。
四、总结
在云计算与互联网技术非常完善的今天,对于大多数初创互联网公司而言,技术几乎不会成为创业的障碍。如果业务模式正确,得到市场的认可和资本的追捧,业务规模迅速发展,即使技术上出现一些差错和滞后,也基本不会对业务发展造成重大伤害。宅米在自身短暂的发展历程中,快速的业务发展不断对技术提出各种各样的挑战,技术团队也曾手忙脚乱穷于应对,但是通过不断的自我进化,经历一次又一次的脱胎换骨和浴火重生,终究还是成长起来了。
编辑推荐:架构技术实践系列文章(部分):
秦鹏:从应用到平台,云服务架构的演进过程李智慧:宅米网技术变迁——初创互联网公司的技术发展之路
陶文质:分布式系统设计的求生之路
魏晓军: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”大流量的技术实践
架构师于小波:魅族实时消息推送架构
相关文章推荐
- 宅米网技术变迁——初创互联网公司的技术发展之路
- 宅米网技术变迁——初创互联网公司的技术发展之路
- 宅米网技术变迁——初创互联网公司的技术发展之路
- 互联网技术发展之路(3)- 牛逼公司的技术架构都是这个范
- BAT解密:互联网技术发展之路(3)- 牛逼公司的技术架构都是这个范
- BAT解密:互联网技术发展之路(3)- 牛逼公司的技术架构都是这个范
- BAT解密:互联网技术发展之路(3)- 牛逼公司的技术架构都是这个范
- BAT解密:互联网技术发展之路(3)- 牛逼公司的技术架构都是这个范
- BAT解密:互联网技术发展之路(1) - 技术发展的驱动力
- 关于业务高速发展的互联网公司技术架构演化的一些看法
- BAT解密:互联网技术发展之路(5)- 开发层技术剖析
- BAT解密:互联网技术发展之路(4)- 存储层技术剖析
- BAT解密:互联网技术发展之路(9)- 业务层技术剖析
- BAT解密:互联网技术发展之路(4)- 存储层技术剖析
- 互联网技术发展之路(4)- 存储层技术剖析
- BAT解密:互联网技术发展之路(1) - 技术发展的驱动力
- BAT解密:互联网技术发展之路(7)- 网络层技术剖析
- BAT解密:互联网技术发展之路(8)- 用户层技术剖析
- 互联网技术发展之路(5)- 开发层技术剖析
- BAT解密:互联网技术发展之路(7)- 网络层技术剖析