最近幾年，互聯網創業浪潮風起云涌，各類互聯網創業公司如雨后春筍般成立。技術做為互聯網創業重要的一個組成部分，也前所未有的受到重視。互聯網企業的發展通常都是爆發式增長，在極短的時間內，業務規模、用戶量成百上千倍的增長，對網站的技術架構提出極大的挑戰。

本文以宅米網為例，跟大家分享在一個典型的互聯網創業公司中，技術如何快速響應業務變化，不斷重構優化系統架構，滿足業務的需求。技術團隊又是如何不斷地重組優化快速發展壯大，適應業務和技術架構的變化。

一、宅米業務規模變遷

宅米成立于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

技術部成立專門的架構組，進行性能測試、性能優化、架構重構、流程改進等業務無關的技術改造，并對產品研發團隊進行技術支持，是技術部的救火隊和特種兵。

四、總結

在云計算與互聯網技術非常完善的今天，對于大多數初創互聯網公司而言，技術幾乎不會成為創業的障礙。如果業務模式正確，得到市場的認可和資本的追捧，業務規模迅速發展，即使技術上出現一些差錯和滯后，也基本不會對業務發展造成重大傷害。?
宅米在自身短暫的發展歷程中，快速的業務發展不斷對技術提出各種各樣的挑戰，技術團隊也曾手忙腳亂窮于應對，但是通過不斷的自我進化，經歷一次又一次的脫胎換骨和浴火重生，終究還是成長起來了。

總結

以上是生活随笔為你收集整理的宅米网技术变迁——初创互联网公司的技术发展之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。