享學課堂特邀做者:老顧
咱們小夥伴們是否是常常看到網上一些集羣、高可用、高併發、負載均衡等關鍵詞,有不少種方案、以及應用場景中都有相關的介紹。今天老顧就帶着你們一塊兒看一下,一整套大型網站會有哪些負載均衡方案場景。java
創業初期不少資源的限制,一切以業務爲核心,可以正常使用就能夠了,由於流量不是很大,因此這個階段的什麼集羣、高可用、負載均衡就沒有了
nginx
業務獲得市場承認,用戶活躍基數慢慢變大,須要考慮****到系統的可用性和負載問題
web
web服務的集羣化,就會碰到用戶session的問題,因此須要添加一臺redis服務器作分佈式會話。redis
有些系統的session會話方案,採用本地化方案,利用jwt+token的方式,他們會不須要redis服務器保存session會話。數據庫
也有用jwt 和redis會話服務器相結合的方案,這樣能夠解決jwt的缺點問題。這裏老顧就很少講了。緩存
這個階段是業務發展最快的階段,業務的多變性,以及用戶流量已經到了必定的規模,要考慮系統的可用性了,數據量也有必定的規模。這時是系統進入促步改造的時期。安全
爲了保證業務的多變,咱們須要把各自業務進行解耦,這邊須要的技術Dubbo或Spring Cloud微服務框架。這兩個框架都支持微服務集羣部署,以及調用方的負載均衡。以下圖的訂單微服務會部署幾個訂單微服務,造成集羣,web服務調用方會作負載均衡的調用。這邊就涉及到了第二個負載均衡的場景,是利用微服務框架自身的功能。
服務器
活躍用戶的增大,會對DB數據庫的訪問壓力過大,這個時候會考慮增長緩存層來幫助DB減壓。在進行分佈式緩存進行規劃時,會用到redis集羣做爲緩存。redis集羣方案中利用哈希槽的方式,達到了緩存數據量的拆分,以及負載均衡。這個就是第三個負載均衡場景
網絡
用戶併發到了幾千的時候,就要考慮到nginx的高可用,雖然nginx的性能比較高,但也經不起量大啊。利用LVS來實現nginx的高可用和負載均衡,這個又是一個負載均衡場景
session
此階段的業務已經趨於穩定,數據量也越有越大,用戶活躍也很大;業務複雜度很高,已經業務流程多變,市場規模發展到全國,有多機房多區域的部署的需求。公司規模大了之後,網絡安全就顯得尤其重要。系統必定要保證穩定
數據庫單表若是超過300多萬條記錄時,就要考慮到分表;數據庫的IO操做已經一直處於高負荷狀態,就能夠考慮把業務進行拆分到不一樣的DB中,以及數據庫的主從設計實現讀寫分離,設計來下降DB負載和高可用。
分庫分表中能夠採用兩種方案,一種代理層方案,如:MyCat框架;一種是客戶端實現,如sharding-jdbc。這個又是一種在數據庫層的負載均衡場景
業務的複雜度高,須要很好的拆分業務,更進一步的業務解耦,以及高併發下限流會用到消息中間件,如:RocketMQ,RabbitMQ。
還有分佈式事務中,爲了保證最終一致性,也會用到消息中間件。
消息中間件是天生的集羣化,保證消息中間件的高可用以及負載均衡,有這個是消息隊列層的負載均衡場景。
在分佈式架構下,爲了進行統一的路由,鑑權,限流,監控等;這個時候就要上網關,如今網關框架爲:Kong,Zuul,GateWay,Soul等,這些框架也是集羣化的。部署到nginx層下面(kong能夠直接替換nginx,由於就是在nginx基礎上設計的)架設網關層。這個是網關層的負載均衡場景
業務時全國市場,甚至全球市場的話,因爲地區網絡節點是按照地區架設的,因此要保證多地區可以快速訪問咱們的網站,這個時候就須要作多機房的設計。多機房的設計就是利用了DNS,這個就是DNS層的負載均衡
到達這一步的話,通常在同一機房下,會部署幾套系統集羣方案,這個時候通常在機房裏面會加入硬件負載均衡器,如:F5,A10;硬件負載均衡器是蠻貴的,不過公司已經發展到這個地步了,應該有錢了。
涉及到跨機房,系統設計的時候就會很是複雜,尤爲要考慮到機房間數據如何共享,同步?這些點老顧在之後的文章中會介紹,跨機房要解決什麼問題?
有個共同點就是大型系統不容許有單點故障,就須要集羣化,一旦有集羣化的地方,確定會有負載均衡的場景應用。
大型系統的發展,是根據業務發展而來的,在業務沒有達到必定的程度時,要選擇合適的系統設計,不能超前選擇很複雜的方案,會致使開發週期會很長,系統也會變的複雜,沒有必要,這一點是技術老大須要重視的。
END
歡迎長按下圖關注公衆號:享學課堂online!
公衆號後臺回覆【java】,獲取精選準備的架構學習資料(視頻+文檔+架構筆記)