歡迎關注頭條號：老顧聊技術

精品原創(chuàng)技術分享，知識的組裝工

---

目錄

1. 前言
2. 創(chuàng)業(yè)階段
3. 小型階段
4. 中型階段
5. 大型階段
6. 總結

前言

我們小伙伴們是不是經(jīng)?？吹骄W(wǎng)上一些集群、高可用、高并發(fā)、負載均衡等關鍵詞，有很多種方案、以及應用場景中都有相關的介紹。今天老顧就帶著大家一起看一下，一整套大型網(wǎng)站會有哪些負載均衡方案場景。

創(chuàng)業(yè)階段

創(chuàng)業(yè)初期很多資源的限制，一切以業(yè)務為核心，能夠正常使用就可以了，因為流量不是很大，所以這個階段的什么集群、高可用、負載均衡就沒有了

這個階段服務器的不可用，影響不是太大，因為在嘗試階段，都是種子用戶進行嘗試業(yè)務

小型階段

業(yè)務得到市場認可，用戶活躍基數(shù)慢慢變大，需要考慮到系統(tǒng)的可用性和負載問題

到這個階段一般會保證web應用服務的可用性和負載，做Web應用集群。這個利用nginx的負載均衡的功能。保證用戶基本服務。這里就第一個負載均衡場景。

web服務的集群化，就會碰到用戶session的問題，所以需要添加一臺redis服務器做分布式會話。

有些系統(tǒng)的session會話方案，采用本地化方案，利用jwt+token的方式，他們會不需要redis服務器保存session會話。

也有用jwt 和 redis會話服務器相結合的方案，這樣可以解決jwt的缺點問題。這里老顧就不多講了。

中型階段

這個階段是業(yè)務發(fā)展最快的階段，業(yè)務的多變性，以及用戶流量已經(jīng)到了一定的規(guī)模，要考慮系統(tǒng)的可用性了，數(shù)據(jù)量也有一定的規(guī)模。這時是系統(tǒng)進入促步改造的時期。

一、業(yè)務微服務化

為了保證業(yè)務的多變，我們需要把各自業(yè)務進行解耦，這邊需要的技術Dubbo或Spring Cloud微服務框架。這兩個框架都支持微服務集群部署，以及調(diào)用方的負載均衡。如下圖的訂單微服務會部署幾個訂單微服務，形成集群，web服務調(diào)用方會做負載均衡的調(diào)用。這邊就涉及到了第二個負載均衡的場景，是利用微服務框架自身的功能。

二、分布式緩存

活躍用戶的增大，會對DB數(shù)據(jù)庫的訪問壓力過大，這個時候會考慮增加緩存層來幫助DB減壓。在進行分布式緩存進行規(guī)劃時，會用到redis集群作為緩存。redis集群方案中利用哈希槽的方式，達到了緩存數(shù)據(jù)量的拆分，以及負載均衡。這個就是第三個負載均衡場景

三、nginx集群

用戶并發(fā)到了幾千的時候，就要考慮到nginx的高可用，雖然nginx的性能比較高，但也經(jīng)不起量大啊。利用LVS來實現(xiàn)nginx的高可用和負載均衡，這個又是一個負載均衡場景

大型階段

此階段的業(yè)務已經(jīng)趨于穩(wěn)定，數(shù)據(jù)量也越有越大，用戶活躍也很大；業(yè)務復雜度很高，已經(jīng)業(yè)務流程多變，市場規(guī)模發(fā)展到全國，有多機房多區(qū)域的部署的需求。公司規(guī)模大了以后，網(wǎng)絡安全就顯得尤為重要。系統(tǒng)一定要保證穩(wěn)定

一、分庫分表

數(shù)據(jù)庫單表如果超過300多萬條記錄時，就要考慮到分表；數(shù)據(jù)庫的IO操作已經(jīng)一直處于高負荷狀態(tài)，就可以考慮把業(yè)務進行拆分到不同的DB中，以及數(shù)據(jù)庫的主從設計實現(xiàn)讀寫分離，設計來降低DB負載和高可用。

分庫分表中可以采用兩種方案，一種代理層方案，如：MyCat框架；一種是客戶端實現(xiàn)，如sharding-jdbc。這個又是一種在數(shù)據(jù)庫層的負載均衡場景

二、消息中間件

業(yè)務的復雜度高，需要很好的拆分業(yè)務，更進一步的業(yè)務解耦，以及高并發(fā)下限流會用到消息中間件，如：RocketMQ，RabbitMQ。

還有分布式事務中，為了保證最終一致性，也會用到消息中間件。

消息中間件是天生的集群化，保證消息中間件的高可用以及負載均衡，有這個是消息隊列層的負載均衡場景。

三、網(wǎng)關

在分布式架構下，為了進行統(tǒng)一的路由，鑒權，限流，監(jiān)控等；這個時候就要上網(wǎng)關，現(xiàn)在網(wǎng)關框架為：Kong，Zuul，GateWay，Soul等，這些框架也是集群化的。部署到nginx層下面（kong可以直接替換nginx，因為就是在nginx基礎上設計的）架設網(wǎng)關層。這個是網(wǎng)關層的負載均衡場景

四、跨機房

業(yè)務時全國市場，甚至全球市場的話，因為地區(qū)網(wǎng)絡節(jié)點是按照地區(qū)架設的，所以要保證多地區(qū)能夠快速訪問我們的網(wǎng)站，這個時候就需要做多機房的設計。多機房的設計就是利用了DNS，這個就是DNS層的負載均衡

到達這一步的話，一般在同一機房下，會部署幾套系統(tǒng)集群方案，這個時候一般在機房里面會加入硬件負載均衡器，如：F5，A10；硬件負載均衡器是蠻貴的，不過公司已經(jīng)發(fā)展到這個地步了，應該有錢了。

涉及到跨機房，系統(tǒng)設計的時候就會非常復雜，尤其要考慮到機房間數(shù)據(jù)如何共享，同步？這些點老顧在以后的文章中會介紹，跨機房要解決什么問題？

不允許有單點故障，就需要集群化，一旦有集群化的地方，肯定會有負載均衡的場景應用。

大型系統(tǒng)的發(fā)展，是根據(jù)業(yè)務發(fā)展而來的，在業(yè)務沒有達到一定的程度時，要選擇合適的系統(tǒng)設計，不能超前選擇很復雜的方案，會導致開發(fā)周期會很長，系統(tǒng)也會變的復雜，沒有必要，這一點是技術老大需要重視的。

網(wǎng)頁題目：一整套大型網(wǎng)站會有哪些負載均衡方案場景
標題鏈接：http://m.rwnh.cn/news16/97716.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供手機網(wǎng)站建設、用戶體驗、定制網(wǎng)站、品牌網(wǎng)站建設、網(wǎng)站設計、微信公眾號

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)