知識星球
隨著業務的複雜性增大、系統吞吐量增長，所有功能統一部署難度加大，各個功能模組相互影響使系統變的笨重且脆弱，因此需要對業務進行拆分、對系統進行解耦、對系統內部架構升級，以此來提升系統容量及健壯性。接下來主要分系統拆分和結構演變兩部分介紹：
一、系統拆分
系統拆分從資源角度分為應用拆分和資料庫拆分，而從採用的先後順序則可分為: 水平擴充套件、垂直拆分、業務拆分和水平拆分。
圖1 系統分解原則
水平擴充套件是最初始的解決的手段，也是系統遇到瓶頸的首選方案，主要從以下兩個方面擴充套件：
-
應用加實體，搞叢集，把系統吞吐量擴上去；
-
資料庫利用主從進行讀寫分離，資料庫其實是系統最應該保護的資源。
垂直拆分才是真正開始拆分系統，主要是從業務功能角度拆分。如拆出使用者系統、商品系統、交易系統等。
為瞭解決拆分後各個子系統之間相互依賴呼叫的問題，這時會引入服務呼叫治理。雖然系統複雜度有所加大，但系統基本解耦，穩定性相對提高，做好降級就能避免因其它系統功能異常導致系統崩潰問題。
業務對應的庫也會按照對應的業務拆分出使用者庫、商品庫、交易庫等。
業務拆分主要是針對應用層面按功能特點拆分，如交易拆分出：購物車、結算頁、訂單、秒殺等系統。然後根據業務的特點，針對性做處理，如秒殺系統，由於同時參加秒殺的商品有限，可以提前把商品資訊載入到JVM快取中，自身減少外部呼叫提高效能，同時商品系統也減輕壓力。
資料庫拆分也可以分為幾步：垂直分表、垂直分庫、水平分表、水平分庫分表，
-
垂直分表是指大表拆多張小表，可以根據欄位更新或查詢頻次拆分；
圖2 商品表拆分
-
垂直分庫是指按業務拆庫，如拆出訂單庫、商品庫、使用者庫等
-
水平分表是解決資料量大，把一張表拆成多張表；
-
水平分庫分表是更進一步拆分表。
圖3 分庫分表
服務分層，系統服務積木化，拆分功能與非功能系統、業務組合的系統，如最近比較火的大中臺或前臺拆分，中臺為積木元件，承擔服務功能輸出；前臺更多的是組合積木服務，及時響應業務發展，如在電商網站單品頁能看見主圖、價格、庫存、優惠券或推薦等資訊，都是組合各積木元件呈現。
資料庫也可以進行冷熱資料分離，過期或過季商品可以歸檔，比如諾基亞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 複雜的結構
三、最後
系統結構慢慢變複雜，穩定性、健壯性逐漸提高；技術選擇都需要結合業務痛點、技術儲備以及資源情況，否則就有些不切實際，泛泛而談。
以上是近幾年自己經歷的技術變革及升級的總結，後續可以針對個別點進行詳細分享。系統拆分的最後是微服務，結構的演變是技術的升級。
-
作者：徐賢軍
-
來源：京東技術訂閱號
推薦閱讀：
溫馨提示：
請搜尋“ICT_Architect”或“掃一掃”二維碼關註公眾號，點選原文連結獲取更多電子書詳情。
求知若渴, 虛心若愚
