京東系統架構師如何讓笨重的架構變得靈巧

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

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

系統拆分

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

從採用的前後順序可分爲：水平擴展、垂直拆分、業務拆分、水平拆分；

                                                                                                 圖1 系統分解原則

一、水平擴展

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

• 應用加實例，搞集羣，把系統吞吐量擴上去。
• 數據庫利用主從進行讀寫分離，數據庫實際上是系統最應該保護的資源。

二、垂直拆分

垂直拆分纔是真正開始拆分系統，主要是從業務功能角度拆分。如拆出用戶系統、商品系統、交易系統等。

爲了解決拆分以後各個子系統之間相互依賴調用的問題，這時會引入服務調用治理。系統複雜度有所加大，但系統基本解耦，穩定性相對提升，作好降級就能避免因其餘系統異常引發系統總體崩潰。

 

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

三、業務拆分

業務拆分主要是針對應用層面按功能特色拆分，如交易拆分出：購物車、結算頁、訂單、秒殺等系統。而後根據業務的特色，針對性作處理，如秒殺系統，因爲同時參加秒殺的商品有限，能夠提早把商品信息加載到JVM緩存中，自身減小外部調用提升性能，同時商品系統也減輕壓力。

數據庫拆分也能夠分爲幾步：垂直分表、垂直分庫、水平分表、水平分庫分表；

垂直分表是指大表拆多張小表，能夠根據字段更新或查詢頻次拆分；

 

 

圖2 商品表拆分

 

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

 

水平分表是解決數據量大，把一張表拆成多張表；

 

水平分庫分表是更進一步拆分表；

 

 

圖3 分庫分表

 

四、水平拆分

 

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

 

數據庫也能夠進行冷熱數據分離；過時或過季商品能夠歸檔，好比諾基亞3210手機，早已經停產且沒有銷售；用戶查看訂單時，更多的只是查看最近一、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開發、架構優化上有較豐富實戰經歷。

 

出處：https://mp.weixin.qq.com/s/kgtWFS_ZznoZxj442C6fzA

 

 

版權申明：內容來源網絡，版權歸原創者全部。除非沒法確認，咱們都會標明做者及出處，若有侵權煩請告知，咱們會當即刪除並表示歉意。謝謝。