如何讓笨重的架構變靈巧？

尋夢新聞LINE@每日推播熱門推薦文章，趣聞不漏接❤️

加入LINE好友

作者介紹

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

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

接下來主要分兩部分介紹：

系統拆分

結構演變

一、系統拆分

系統拆分從資源角度分為應用拆分和數據庫拆分，而從採用的先後順序則可分為：

水平擴展；

垂直拆分；

業務拆分；

水平拆分。

圖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組合。