分佈式架構 高可用
本文將通過自建架構圖 進行講解
如圖採用了分佈式、微服務架構，將傳統系統進行重構後的效果
微服務架構體系對多個層面進行探索、分析和優化，本文不在詳細闡述
微服務、分佈式架構根據公司、企業需求定製化構造而來，目的細化模塊間的調用，鏈路更加清晰明瞭，不同環節高可用方案不同，優化手段也存在差異。
分析思考
如果系統高峯期間可以處理500W/S 請求流量，那麼當請求到達1000W/S請求流量時系統是否有安全隱患？需要從哪些方面進行優化？
-
系統可以撐500W/S請求，說明系統500之上都有可能，可以建造一套防生產環境用來進行內部全鏈路業務壓測、外部流量容災、限流測試，通過此舉可以詳細發現系統哪個環節處於瓶頸，從來進行具體優化
-
如上圖可以通過水平擴展方式從來提升整體處理能力
- F5是瓶頸，外界可以通過多個IP進來，DNS輪詢負載到多套F5集羣，正常情況F5不會存在瓶頸。
- Nginx負載過高，圖上是部署2套Nginx節點，進行估算後可以水平增加Nginx節點
- Varnish緩存基於內存存儲，正常存在內存不夠情況，當出現後可以增加Varnish節點或增加內存分配
- 業務模塊 可以把相同模塊分別部署多份，從而提高服務吞吐量
- Rocketmq高性能消息服務器，單臺可處理千萬級別消息。當消息發送和消費積壓嚴重，Broken負載過高後，可以進行水平擴展（Broken、Provider、Consumer）集羣
- Redis高性能緩存服務器，如出現單臺負載過大，也可以通過擴展集羣模式從而提供高效服務
- Mysql數據庫 當出現連接數佔滿/不夠，數據庫查詢緩慢，可通過擴展集羣模式從而提高數據處理效率，Mysql相關優化後續文章會詳細講解
以上是服務器部署圖
通過部署圖可以發現
- 通過Nginx可指定URL進行輪詢調用，意味着系統內部請求可以通過分流方式從而規避風險
- 如特殊消耗性能相關入口可以分發到單獨服務器從而進行處理
- 針對服務器相關節點進行監控，如zabbix，提前預知系統處理情況
總結：
分佈式架構高可用可以針對不同渠道鏈路進行探針監控，提前預知其存在風險點，然後通過輪詢、切換等方式讓其故障轉移，不影響業務正常使用運轉。其中最爲複雜體現在故障期間來回切換所產生的髒數據、重複數據、部分數據丟失等問題。需要進行系統篩選，必要時需要人工干預處理。
作者簡介：張程 技術研究
更多文章請關注微信公衆號：zachary分解獅 (frankly0423)
