隨著業(yè)務的復雜性增大、系統(tǒng)吞吐量增長，所有功能統(tǒng)一部署難度加大，各個功能模塊相互影響，使系統(tǒng)變的笨重且脆弱;因此需要對業(yè)務進行拆分、對系統(tǒng)進行解耦、對系統(tǒng)內部架構升級，來提升系統(tǒng)容量及健壯性。

接下來主要分兩部分介紹：系統(tǒng)拆分與結構演變;

一、系統(tǒng)拆分

系統(tǒng)拆分從資源角度分為：應用拆分和數(shù)據(jù)庫拆分;

從采用的先后順序可分為：水平擴展、垂直拆分、業(yè)務拆分、水平拆分;

圖1 系統(tǒng)分解原則

1. 水平擴展

水平擴展是最初始的解決的手段，也是系統(tǒng)遇到瓶頸的***方案，主要從以下兩個方面擴展：

• 應用加實例，搞集群，把系統(tǒng)吞吐量擴上去。
• 數(shù)據(jù)庫利用主從進行讀寫分離，數(shù)據(jù)庫其實是系統(tǒng)最應該保護的資源。

2. 垂直拆分

垂直拆分才是真正開始拆分系統(tǒng)，主要是從業(yè)務功能角度拆分。如拆出用戶系統(tǒng)、商品系統(tǒng)、交易系統(tǒng)等。為了解決拆分后各個子系統(tǒng)之間相互依賴調用的問題，這時會引入服務調用治理。系統(tǒng)復雜度有所加大，但系統(tǒng)基本解耦，穩(wěn)定性相對提高，做好降級就能避免因其它系統(tǒng)功能異常導致系統(tǒng)崩潰。

業(yè)務對應的庫也會按照對應的業(yè)務進行拆分出用戶庫、商品庫、交易庫等。

3. 業(yè)務拆分

業(yè)務拆分主要是針對應用層面按功能特點拆分，如交易拆分出：購物車、結算頁、訂單、秒殺等系統(tǒng)。然后根據(jù)業(yè)務的特點，針對性做處理，如秒殺系統(tǒng)，由于同時參加秒殺的商品有限，可以提前把商品信息加載到JVM緩存中，自身減少外部調用提高性能，同時商品系統(tǒng)也減輕壓力。

數(shù)據(jù)庫拆分也可以分為幾步：垂直分表、垂直分庫、水平分表、水平分庫分表。

• 垂直分表是指大表拆多張小表，可以根據(jù)字段更新或查詢頻次拆分;



圖2 商品表拆分

• 垂直分庫是指按業(yè)務拆庫，如拆出訂單庫、商品庫、用戶庫等
• 水平分表是解決數(shù)據(jù)量大，把一張表拆成多張表;
• 水平分庫分表是更進一步拆分表;

圖3 分庫分表

4. 水平拆分

服務分層，系統(tǒng)服務積木化，拆分功能與非功能系統(tǒng)，以及業(yè)務組合的系統(tǒng)，如最近比較火的大中臺或前臺拆分;中臺為積木組件，承擔服務功能輸出。前臺更多的是組合積木服務，及時響應業(yè)務發(fā)展，如在電商網站單品頁能看見主圖、價格、庫存、優(yōu)惠券或推薦等信息，都是組合各積木組件呈現(xiàn)。

數(shù)據(jù)庫也可以進行冷熱數(shù)據(jù)分離;過期或過季商品可以歸檔，比如諾基亞3210手機，早已經停產且沒有銷售;用戶查看訂單時，更多的只是查看最近1、2年信息，2年前數(shù)據(jù)查看量少，在存儲設計時可以區(qū)別處理。

二、結構演變

結構演變主要是隨著系統(tǒng)復雜度增加及對性能要求提高而不得不做的系統(tǒng)內部架構升級;

早期系統(tǒng)基本是應用直聯(lián)數(shù)據(jù)庫，但在系統(tǒng)進行拆分后，功能本系統(tǒng)不能單獨完成，需要依賴其它系統(tǒng)，就出現(xiàn)遠程調用;

圖4 早期應用結構

隨著自身系統(tǒng)的業(yè)務發(fā)展，對性能要求高，而數(shù)據(jù)庫一定程度上成為瓶頸，就會引入緩存及索引，分別解決key-value及復雜檢索;索引加緩存現(xiàn)在已經成為解決高并發(fā)的基本方案，但在實施過程會有所區(qū)別;

14年對3億熱數(shù)據(jù)的系統(tǒng)升級時，技術選型為solr+redis，考慮到數(shù)據(jù)量過大，數(shù)據(jù)在solr中只存index，而結果只存并返回主鍵id，再通過id從redis中讀取數(shù)據(jù)，redis也不存放全部數(shù)據(jù)，數(shù)據(jù)設置過期時間，若未***redis，回源數(shù)據(jù)庫查詢并反寫redis;主要考慮資源與性能的平衡，solr的存儲減少及IO性能提高，結果數(shù)據(jù)只在redis存放一份，redis的數(shù)據(jù)經過運行大部分是熱數(shù)據(jù);當然現(xiàn)在也流行ES+Hbase組合。

圖5 增加緩存及索引

對于頻繁使用的數(shù)據(jù)，從集中緩存讀取，不一定達到性能要求，可以考慮把數(shù)據(jù)入JVM緩存，如類目信息，類目是電商系統(tǒng)基本數(shù)據(jù)，數(shù)據(jù)量不多，調用量大;

個別情況下，使用ThreadLocal做線程內緩存也是種有效手段，但需要考慮數(shù)據(jù)清除及有效性;

在修改商品信息時，業(yè)務對商品信息的校驗有名稱長度、狀態(tài)、庫存及各業(yè)務模式等，而為了參數(shù)的統(tǒng)一校驗方法參數(shù)為商品編號，導致各校驗方法都需要讀取一次商品，使用線程緩存可以解決該問題，性能提高了盡20ms，讀取商品每分鐘減少近萬次;

圖6 增加本地緩存

有時所依賴系統(tǒng)性能不太穩(wěn)定，避免出現(xiàn)因第三方系統(tǒng)影響系統(tǒng)，把依賴的服務進行數(shù)據(jù)閉環(huán)，與Dao一樣當成系統(tǒng)的數(shù)據(jù)源;如商品系統(tǒng)強依賴商家系統(tǒng)的商家信息服務，若商家服務不穩(wěn)定，商品系統(tǒng)一半服務都不穩(wěn)定，采取對商家信息緩存一份，降低外部風險，把風險控制在自己手上;

圖7 遠程服務進化成數(shù)據(jù)源

用戶體驗最近越來越重視，系統(tǒng)響應時間性能要求也越來越高，異步化是很好的一種選擇：消息中間件;電商下單就是個很好的案例，在用戶點擊下單時，服務端不直接保存數(shù)據(jù)，給訂單系統(tǒng)發(fā)送消息，就直接返回支付頁面，在用戶支付過程中，訂單系統(tǒng)異步進行數(shù)據(jù)保存;

業(yè)務層、數(shù)據(jù)層的范圍越來越寬泛，業(yè)務層可以分為基礎服務與組合服務;數(shù)據(jù)層分為數(shù)據(jù)源與索引緩存;依賴的技術或中間件需要有效的結合，用于解決系統(tǒng)所遇到各種問題。

圖8 復雜的結構

三、***

系統(tǒng)結構慢慢變復雜，穩(wěn)定性、健壯性逐漸提高;技術選擇都需要結合業(yè)務痛點、技術儲備以及資源情況，否則就有些不切實際，泛泛而談;

以上是近幾年自己經歷的技術變革及升級的總結，后續(xù)可以針對個別點進行詳細分享。

系統(tǒng)拆分的***是微服務，結構的演變是技術的升級。

作者：徐賢軍，京東系統(tǒng)架構師，從事架構設計與開發(fā)工作，熟悉各種開源軟件架構。在Web開發(fā)、架構優(yōu)化上有較豐富實戰(zhàn)經歷。

【本文來自51CTO專欄作者張開濤的微信公眾號(開濤的博客)，公眾號id: kaitao-1234567】

戳這里，看該作者更多好文