圖片來源：Unsplash

作者丨徐賢軍

來源丨徐賢軍 架構師技術聯盟

如需轉載，請聯系原作者授權

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

系統拆分

系統拆分從資源角度分為應用拆分和數據庫拆分，而從采用的先后順序則可分為:?水平擴展、垂直拆分、業務拆分和水平拆分。

圖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 復雜的結構

最后

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

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

完

投稿啦！！！

精彩繼續

CSDN作為國內專業的云計算服務平臺，目前提供云計算、大數據、虛擬化、數據中心、OpenStack、CloudStack、機器學習、智能算法等相關云計算觀點、技術、平臺、實踐、云產業咨詢等服務。CSDN?公眾號也一直堅持「與千萬技術人共成長」的理念，深度解讀行業內熱門技術與場景應用，致力于讓所有開發者保持敏銳的技術嗅覺、對行業趨勢與技術獲得更廣闊的認知。

文章題材

• 首先你需要關注我們的公眾號“CSDN云計算”，這樣你會更準確了解我們需要的文章風格；

• 側重于云計算領域相關的文章，可以是技術、運維、趨勢等方面的務實內容；

• 原創，要求文章有鮮明觀點和看法。

投稿須知

• ?稿費：根據原創性、實用性和時效性等方面進行審核，通過的文章會發布在本微信平臺。一經采用，我們將支付作者酬勞。酬勞可能不多，這代表的是一個心意，更多是因為愛好，是有識之士抒發胸懷的一種方式；

• 字數要求：稿件字數以2K-8K為宜，少于2K或多于8K都會一定程度降低閱讀愉悅感；

• 投稿郵箱：lijy@csdn.net。或者添加微信表明來意，微信號：tangguoyemeng。請備注投稿+姓名+公司職位。

  
  

如果咱們的合作穩定又愉快，還可以簽訂合同長期合作哦！

總結

以上是生活随笔為你收集整理的如何让笨重的系统架构变灵巧？的全部內容，希望文章能夠幫你解決所遇到的問題。

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