分佈式架構 高可用

分佈式架構 高可用

 

本文將經過架構圖 進行講解

如圖採用了分佈式、微服務架構，將傳統系統進行重構後的效果

微服務架構體系對多個層面進行探索、分析和優化，本文不在詳細闡述

微服務、分佈式架構根據公司、企業需求定製化構造而來，目的細化模塊間的調用，鏈路更加清晰明瞭，不一樣環節高可用方案不一樣，優化手段也存在差別。

分析思考

若是系統高峯期間能夠處理500W/S 請求流量，那麼當請求到達1000W/S請求流量時系統是否有安全隱患？須要從哪些方面進行優化？

• 系統能夠撐500W/S請求，說明系統500之上都有可能，能夠建造一套防生產環境用來進行內部全鏈路業務壓測、外部流量容災、限流測試，經過此舉能夠詳細發現系統哪一個環節處於瓶頸，歷來進行具體優化

• 如上圖能夠經過水平擴展方式歷來提高總體處理能力

1. F5是瓶頸，外界能夠經過多個IP進來，DNS輪詢負載到多套F5集羣，正常狀況F5不會存在瓶頸。
2. Nginx負載太高，圖上是部署2套Nginx節點，進行估算後能夠水平增長Nginx節點
3. Varnish緩存基於內存存儲，正常存在內存不夠狀況，當出現後能夠增長Varnish節點或增長內存分配
4. 業務模塊 能夠把相同模塊分別部署多份，從而提升服務吞吐量
5. Rocketmq高性能消息服務器，單臺可處理千萬級別消息。當消息發送和消費積壓嚴重，Broken負載太高後，能夠進行水平擴展（Broken、Provider、Consumer）集羣
6. Redis高性能緩存服務器，如出現單臺負載過大，也能夠經過擴展集羣模式從而提供高效服務
7. Mysql數據庫 當出現鏈接數佔滿/不夠，數據庫查詢緩慢，可經過擴展集羣模式從而提升數據處理效率，Mysql相關優化後續文章會詳細講解

以上是服務器部署圖

經過部署圖能夠發現

• 經過Nginx可指定URL進行輪詢調用，意味着系統內部請求能夠經過分流方式從而規避風險
• 如特殊消耗性能相關入口能夠分發到單獨服務器從而進行處理
• 針對服務器相關節點進行監控，如zabbix，prom 提早預知系統處理狀況

總結：

分佈式架構高可用能夠針對不一樣渠道鏈路進行探針監控，提早預知其存在風險點，而後經過輪詢、切換等方式讓其故障轉移，不影響業務正常使用運轉。其中最爲複雜體如今故障期間來回切換所產生的髒數據、重複數據、部分數據丟失等問題。須要進行系統篩選，必要時須要人工干預處理。

做者簡介：張程 技術研究

更多文章請關注微信公衆號：zachary分解獅 (frankly0423)