随着業務的複雜性增大、系統吞吐量增長，所有功能統一部署難度加大，各個功能子產品互相影響使系統變的笨重且脆弱，是以需要對業務進行拆分、對系統進行解耦、對系統内部架構更新，以此來提升系統容量及健壯性。
接下來主要分兩部分介紹：
系統拆分
結構演變
一、系統拆分
系統拆分從資源角度分為應用拆分和資料庫拆分，而從采用的先後順序則可分為：
水準擴充；
垂直拆分；
業務拆分；
水準拆分。
圖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 複雜的結構
三、最後
系統結構慢慢變複雜，穩定性、健壯性逐漸提高；技術選擇都需要結合業務痛點、技術儲備以及資源情況，否則就有些不切實際，泛泛而談。
以上是近幾年自己經曆的技術變革及更新的總結，後續可以針對個别點進行詳細分享。系統拆分的最後是微服務，結構的演變是技術的更新。
原文釋出時間為：2018-07-17
本文來自雲栖社群合作夥伴“
DBAplus社群”，了解相關資訊可以關注
“DBAplus社群”。