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

接下來主要分兩部分介紹：系統拆分與結構演變。

一、系統拆分

系統拆分從資源角度分為：應用拆分和數據庫拆分。

從采用的先后順序可分為：水平擴展、垂直拆分、業務拆分、水平拆分。

圖1 系統分解原則

1. 水平擴展

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

應用加實例，搞集群，把系統吞吐量擴上去。

數據庫利用主從進行讀寫分離，數據庫其實是系統最應該保護的資源。

2. 垂直拆分

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

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

3. 業務拆分

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

數據庫拆分也可以分為幾步：垂直分表、垂直分庫、水平分表、水平分庫分表;

垂直分表是指大表拆多張小表，可以根據字段更新或查詢頻次拆分。

圖2 商品表拆分

垂直分庫是指按業務拆庫，如拆出訂單庫、商品庫、用戶庫等。

• 水平分表是解決數據量大，把一張表拆成多張表;
• 水平分庫分表是更進一步拆分表;

圖3 分庫分表

4. 水平拆分

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

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

二、結構演變

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

早期系統基本是應用直聯數據庫，但在系統進行拆分后，功能本系統不能單獨完成，需要依賴其它系統，就出現遠程調用;

圖4 早期應用結構

隨著自身系統的業務發展，對性能要求高，而數據庫一定程度上成為瓶頸，就會引入緩存及索引，分別解決key-value及復雜檢索;索引加緩存現在已經成為解決高并發的基本方案，但在實施過程會有所區別;

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

圖5 增加緩存及索引

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

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

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

圖6 增加本地緩存

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

圖7 遠程服務進化成數據源

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

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

圖8 復雜的結構

三、***

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

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

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

作者：徐賢軍，京東系統架構師，從事架構設計與開發工作，熟悉各種開源軟件架構。在Web開發、架構優化上有較豐富實戰經歷。

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

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