歡迎光臨
每天分享高質量文章

如何讓笨重的系統架構變靈巧?

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

一、系統拆分

系統拆分從資源角度分為應用拆分和資料庫拆分,而從採用的先後順序則可分為: 水平擴展、垂直拆分、業務拆分和水平拆分

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

三、最後

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

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

  • 作者:徐賢軍

  • 來源:京東技術訂閱號

推薦閱讀:

溫馨提示:

請搜索“ICT_Architect”“掃一掃”二維碼關註公眾號,點擊原文鏈接獲取更多電子書詳情。

求知若渴, 虛心若愚

赞(0)

分享創造快樂