9A文系統(tǒng)架構(gòu)優(yōu)化最佳實踐

1、MeiWei 81 重點借鑒文檔】系統(tǒng)架構(gòu)優(yōu)化最佳實踐看京東系統(tǒng)架構(gòu)師如何讓笨重的架構(gòu)變得靈巧MeiWei_81 重點借鑒文檔】MeiWei 81 重點借鑒文檔】目錄一、項目背景 . 3二、系統(tǒng)拆分 . 31 、水平擴展 . 32 、垂直拆分 . 43 、業(yè)務(wù)拆分 . 44 、水平拆分 . 6三、結(jié)構(gòu)演變 . 6四、結(jié)語 . 11MeiWei_81 重點借鑒文檔】系統(tǒng)拆分MeiWei 81 重點借鑒文檔】一、 項目背景隨著業(yè)務(wù)的復(fù)雜性增大、系統(tǒng)吞吐量增長，所有功能統(tǒng)一部署難度加大，各個功能模塊相互影 響，使系統(tǒng)變的笨重且脆弱；因此需要對業(yè)務(wù)進(jìn)行拆分、對系統(tǒng)進(jìn)行解耦、對系統(tǒng)內(nèi)部架構(gòu)升 級，來提升

2、系統(tǒng)容量及健壯性。接下來主要分兩部分介紹：系統(tǒng)拆分與結(jié)構(gòu)演變；系統(tǒng)拆分從資源角度分為：應(yīng)用拆分和數(shù)據(jù)庫拆分；從采用的先后順序可分為：水平擴展、垂直拆分、業(yè)務(wù)拆分、水平拆分；圖1 系統(tǒng)分解原則1、水平擴展 水平擴展是最初始的解決的手段，也是系統(tǒng)遇到瓶頸的首選方案，主要從以下兩個方面擴展： o 應(yīng)用加實例，搞集群，把系統(tǒng)吞吐量擴上去。o 數(shù)據(jù)庫利用主從進(jìn)行讀寫分離，數(shù)據(jù)庫其實是系統(tǒng)最應(yīng)該保護(hù)的資源。2 、垂直拆分 垂直拆分才是真正開始拆分系統(tǒng)，主要是從業(yè)務(wù)功能角度拆分。如拆出用戶系統(tǒng)、商品系統(tǒng)、 交易系統(tǒng)等。 為了解決拆分后各個子系統(tǒng)之間相互依賴調(diào)用的問題， 這時會引入服務(wù)調(diào)用治理 系統(tǒng)復(fù)雜度有所

3、加大，但系統(tǒng)基本解耦，穩(wěn)定性相對提高，做好降級就能避免因其它系統(tǒng)功能 異常導(dǎo)致系統(tǒng)崩潰。業(yè)務(wù)對應(yīng)的庫也會按照對應(yīng)的業(yè)務(wù)進(jìn)行拆分出用戶庫、商品庫、交易庫等。3、業(yè)務(wù)拆分MeiWei_81 重點借鑒文檔】MeiWei 81 重點借鑒文檔】業(yè)務(wù)拆分主要是針對應(yīng)用層面按功能特點拆分，如交易拆分出：購物車、結(jié)算頁、訂單、秒殺 等系統(tǒng)。然后根據(jù)業(yè)務(wù)的特點，針對性做處理，如秒殺系統(tǒng)，由于同時參加秒殺的商品有限， 可以提前把商品信息加載到 JVM 緩存中，自身減少外部調(diào)用提高性能，同時商品系統(tǒng)也減輕壓 力。數(shù)據(jù)庫拆分也可以分為幾步：垂直分表、垂直分庫、水平分表、水平分庫分表； 垂直分表 是指大表拆多張小表，可

4、以根據(jù)字段更新或查詢頻次拆分；圖 2 商品表拆分 垂直分庫 是指按業(yè)務(wù)拆庫，如拆出訂單庫、商品庫、用戶庫等 水平分表 是解決數(shù)據(jù)量大，把一張表拆成多張表； 水平分庫分表 是更進(jìn)一步拆分表；圖3 分庫分表4 、水平拆分 服務(wù)分層，系統(tǒng)服務(wù)積木化，拆分功能與非功能系統(tǒng)，以及業(yè)務(wù)組合的系統(tǒng)，如最近比較火的 大中臺或前臺拆分；中臺為積木組件，承擔(dān)服務(wù)功能輸出。前臺更多的是組合積木服務(wù)，及時 響應(yīng)業(yè)務(wù)發(fā)展，如在電商網(wǎng)站單品頁能看見主圖、價格、庫存、優(yōu)惠券或推薦等信息，都是組 合各積木組件呈現(xiàn)。數(shù)據(jù)庫也可以進(jìn)行冷熱數(shù)據(jù)分離；過期或過季商品可以歸檔，比如諾基亞 3210 手機，早已經(jīng) 停產(chǎn)且沒有銷售；用戶查

5、看訂單時，更多的只是查看最近1、 2 年信息， 2 年前數(shù)據(jù)查看量少，在存儲設(shè)計時可以區(qū)別處理。MeiWei_81 重點借鑒文檔】MeiWei 81 重點借鑒文檔】三、 結(jié)構(gòu)演變結(jié)構(gòu)演變主要是隨著系統(tǒng)復(fù)雜度增加及對性能要求提高而不得不做的系統(tǒng)內(nèi)部架構(gòu)升級；早期系統(tǒng)基本是應(yīng)用直聯(lián)數(shù)據(jù)庫，但在系統(tǒng)進(jìn)行拆分后，功能本系統(tǒng)不能單獨完成，需要依賴 其它系統(tǒng)，就出現(xiàn)遠(yuǎn)程調(diào)用；圖4 早期應(yīng)用結(jié)構(gòu) 隨著自身系統(tǒng)的業(yè)務(wù)發(fā)展，對性能要求高，而數(shù)據(jù)庫一定程度上成為瓶頸，就會引入緩存及索 引，分別解決 keR-value 及復(fù)雜檢索；索引加緩存現(xiàn)在已經(jīng)成為解決高并發(fā)的基本方案，但在 實施過程會有所區(qū)別；14 年對 3

6、 億熱數(shù)據(jù)的系統(tǒng)升級時，技術(shù)選型為 solr+redis ，考慮到數(shù)據(jù)量過大，數(shù)據(jù)在 solr 中只存 indeR ，而結(jié)果只存并返回主鍵id ，再通過 id 從 redis 中讀取數(shù)據(jù)， redis 也不存放全部數(shù)據(jù)，數(shù)據(jù)設(shè)置過期時間，若未命中 redis ，回源數(shù)據(jù)庫查詢并反寫 redis ；主要考慮資源與 性能的平衡， solr 的存儲減少及 IO 性能提高，結(jié)果數(shù)據(jù)只在 redis 存放一份， redis 的數(shù)據(jù)經(jīng) 過運行大部分是熱數(shù)據(jù)；當(dāng)然現(xiàn)在也流行 ES+Hbase 組合。圖 5 增加緩存及索引對于頻繁使用的數(shù)據(jù)，從集中緩存讀取，不一定達(dá)到性能要求，可以考慮把數(shù)據(jù)入 JVM 緩存，

7、 如類目信息，類目是電商系統(tǒng)基本數(shù)據(jù)，數(shù)據(jù)量不多，調(diào)用量大；個別情況下， 使用 ThreadLocal 做線程內(nèi)緩存也是種有效手段， 但需要考慮數(shù)據(jù)清除及有效性；MeiWei_81 重點借鑒文檔】MeiWei 81 重點借鑒文檔】在修改商品信息時，業(yè)務(wù)對商品信息的校驗有名稱長度、狀態(tài)、庫存及各業(yè)務(wù)模式等，而為了參數(shù)的統(tǒng)一校驗方法參數(shù)為商品編號，導(dǎo)致各校驗方法都需要讀取一次商品，使用線程緩存可以解決該問題，性能提高了盡 20ms ，讀取商品每分鐘減少近萬次；圖6 增加本地緩存有時所依賴系統(tǒng)性能不太穩(wěn)定， 避免出現(xiàn)因第三方系統(tǒng)影響系統(tǒng)， 把依賴的服務(wù)進(jìn)行數(shù)據(jù)閉環(huán)， 與 Dao 一樣當(dāng)成系統(tǒng)的數(shù)據(jù)源

8、；如商品系統(tǒng)強依賴商家系統(tǒng)的商家信息服務(wù)，若商家服務(wù)不穩(wěn) 定，商品系統(tǒng)一半服務(wù)都不穩(wěn)定，采取對商家信息緩存一份，降低外部風(fēng)險，把風(fēng)險控制在自 己手上；圖 7 遠(yuǎn)程服務(wù)進(jìn)化成數(shù)據(jù)源MeiWei_81 重點借鑒文檔】MeiWei 81 重點借鑒文檔】用戶體驗最近越來越重視，系統(tǒng)響應(yīng)時間性能要求也越來越高，異步化是很好的一種選擇：消 息中間件；電商下單就是個很好的案例，在用戶點擊下單時，服務(wù)端不直接保存數(shù)據(jù)，給訂單 系統(tǒng)發(fā)送消息，就直接返回支付頁面，在用戶支付過程中，訂單系統(tǒng)異步進(jìn)行數(shù)據(jù)保存； 業(yè)務(wù)層、數(shù)據(jù)層的范圍越來越寬泛，業(yè)務(wù)層可以分為基礎(chǔ)服務(wù)與組合服務(wù)；數(shù)據(jù)層分為數(shù)據(jù)源 與索引緩存；依賴的技術(shù)或中間件需要有效的結(jié)合，用于解決系統(tǒng)所遇到各種問題。圖 8 復(fù)雜的結(jié)構(gòu)四、 結(jié)語系統(tǒng)結(jié)構(gòu)慢慢變復(fù)雜，穩(wěn)定性、健