網際網路的業務千差萬別，不同的業務分解下來有不同的系統，所以業務層沒有辦法提煉一些公共的系統或者元件，但拋開業務的差異，各個網際網路業務發展最終面臨的問題都是類似的：就是複雜度越來越高，也就是說，業務層面對的主要技術挑戰是“複雜性”。

幸運的是，面對業務層的技術挑戰，我們有一把屠龍寶刀，神擋殺神，佛擋殺佛，不管什麼業務難題，用上屠龍寶刀一試都迎刃而解。這把屠龍寶刀就是“拆”。

複雜性的一個主要原因就是系統越來越龐大，業務越來越多，降低複雜性最好的方式就是“拆”，化整為零、分而治之，將整體複雜性分散到多個子業務或者子系統裡面去。

以一個簡單的電商系統為例：

如上圖，我們這個模擬的電商系統經歷了3個發展階段：

第一階段：所有功能都在1個系統裡面

第二階段：將商品和訂單拆分到2個子系統裡面

第三階段：商品子系統和訂單子系統分別拆分成了更小的3個子系統

以上只是樣例，實際上隨著業務的發展，子系統會越來越多，據說淘寶內部大大小小的已經有成百上千的子系統了。

雖然說“拆”是屠龍寶刀，但也不能亂拆，拆到合適的粒度是一門藝術，拆的太粗複雜度沒有降低，但也不是意味著拆的越細越好，主要原因如下：

1）子系統太多，運維成本會增加，包括系統資源增加、問題定位複雜度增加

2）子系統太多，開發成本可能會增加，例如做一個需求可能要10幾個系統配合

3）子系統太多，子系統的互動又會越來越複雜，單個系統的複雜度降低，但整體的複雜度還是會升高。

我們之前有業務一開始上來就拆了40多個子系統，開發過程中很蛋疼（測試和分工），上線後更蛋疼（上一個功能要10多個系統一起上版本），後來受不了了，1年以後開始將很多系統合併，慢慢的將系統數量減為不到20個。

我個人的經驗就是7+-2原則，也就是說將系統拆分為5 ~ 9 個人能夠維護的粒度，也就是說假如你的團隊有20人，拆分成3 ~ 5個系統是比較合適，即使再拆的更細，最低要保證3個人負責一個系統的粒度，如果出現一個人負責1個系統，甚至一個人要負責多個系統，就說明拆的太細了，會帶來很多問題。

為何按照這個原則來拆分呢？科學研究證明，人腦同時關注的目標大約就是7+-2個，對於一個9個人負責的系統來說，每個人都可以覆蓋到系統的所有方面，如果20個人才能維護一個系統，說明1個人可能要關注20個點，但人很難關注這麼多的點的。

其次為何至少要3個人負責一個系統呢？這是從團隊管理的角度出發的，如果2個人甚至1個人負責一個系統，首先是人員沒有足夠備份，一個人請假或者變動，整個系統的效率就要受到影響；其次如果1個人負責一個或者多個系統，思考難免有遺漏，容易出問題。

除了拆分的粒度需要關注外，運維的配套也需要特別關注，因為不管怎麼拆，系統數量肯定是比以前多了很多，如果按照原始的人工敲命令的方式進行運維，難以支撐不斷增長的系統數量，就會出現運維每天16小時都在執行升級部署和問題處理。

基本的運維配套如下：

1）部署：自動化或者半自動化的部署，避免運維人員執行shell命令或者指令碼的方式去部署

2）日誌採集：需要統一的日誌採集系統，將多個系統的日誌聚合在一個地方，方便出問題的時候快速定位問題

3）監控：需要建立統一的監控平臺監控各個子系統