互聯(lián)網早期，業(yè)務流量比較小并且業(yè)務邏輯比較簡單，單臺服務器便可以滿足基本的需求；但隨著互聯(lián)網的發(fā)展，業(yè)務流量越來越大并且業(yè)務邏輯也越來越復雜，單臺機器的性能問題以及單點問題凸顯了出來，因此需要多臺機器來進行性能的水平擴展以及避免單點故障。但是要如何將不同的用戶的流量分發(fā)到不同的服務器上面呢

早期的方法是使用DNS做負載，通過給客戶端解析不同的IP地址，讓客戶端的流量直接到達各個服務器。但是這種方法有一個很大的缺點就是延時性問題，在做出調度策略改變以后，由于DNS各級節(jié)點的緩存并不會及時的在客戶端生效，而且DNS負載的調度策略比較簡單，無法滿足業(yè)務需求，因此就出現(xiàn)了負載均衡。

客戶端的流量首先會到達負載均衡服務器，由負載均衡服務器通過一定的調度算法將流量分發(fā)到不同的應用服務器上面，同時負載均衡服務器也會對應用服務器做周期性的健康檢查，當發(fā)現(xiàn)故障節(jié)點時便動態(tài)的將節(jié)點從應用服務器集群中剔除，以此來保證應用的高可用。

當一個Web系統(tǒng)從日訪問量10萬逐步增長到1000萬，甚至超過1億的過程中，Web系統(tǒng)承受的壓力會越來越大，在這個過程中，我們會遇到很多的問題。為了解決這些性能壓力帶來問題，我們需要在Web系統(tǒng)架構層面搭建多個層次的緩存機制。在不同的壓力階段，我們會遇到不同的問題，通過搭建不同的服務和架構來解決。

Web負載均衡

Web負載均衡（LoadBalancing），簡單地說就是給我們的服務器集群分配“工作任務”，而采用恰當?shù)姆峙浞绞剑瑢τ诒Ｗo處于后端的Web服務器來說，非常重要。

負載均衡的策略；

1.HTTP重定向

當用戶發(fā)來請求的時候，Web服務器通過修改HTTP響應頭中的Location標記來返回一個新的url，然后瀏覽器再繼續(xù)請求這個新url，實際上就是頁面重定向。通過重定向，來達到“負載均衡”的目標。例如，我們在下載PHP源碼包的時候，點擊下載鏈接時，為了解決不同國家和地域下載速度的問題，它會返回一個離我們近的下載地址。重定向的HTTP返回碼是302，如下圖：

如果使用PHP代碼來實現(xiàn)這個功能，方式如下：

這個重定向非常容易實現(xiàn)，并且可以自定義各種策略。但是，它在大規(guī)模訪問量下，性能不佳。而且，給用戶的體驗也不好，實際請求發(fā)生重定向，增加了網絡延時。

2.反向代理負載均衡

反向代理服務的核心工作主要是轉發(fā)HTTP請求，扮演了瀏覽器端和后臺Web服務器中轉的角色。因為它工作在HTTP層（應用層），也就是網絡七層結構中的第七層，因此也被稱為“七層負載均衡”。可以做反向代理的軟件很多，比較常見的一種是Nginx。

Nginx是一種非常靈活的反向代理軟件，可以自由定制化轉發(fā)策略，分配服務器流量的權重等。反向代理中，常見的一個問題，就是Web服務器存儲的session數(shù)據(jù)，因為一般負載均衡的策略都是隨機分配請求的。同一個登錄用戶的請求，無法保證一定分配到相同的Web機器上，會導致無法找到session的問題。

解決方案主要有兩種：

配置反向代理的轉發(fā)規(guī)則，讓同一個用戶的請求一定落到同一臺機器上（通過分析cookie），復雜的轉發(fā)規(guī)則將會消耗更多的CPU，也增加了代理服務器的負擔。

將session這類的信息，專門用某個獨立服務來存儲，例如Redis/memchache，這個方案是比較推薦的。

反向代理服務，也是可以開啟緩存的，如果開啟了，會增加反向代理的負擔，需要謹慎使用。這種負載均衡策略實現(xiàn)和部署非常簡單，而且性能表現(xiàn)也比較好。但是，它有“單點故障”的問題，如果掛了，會帶來很多的麻煩。而且，到了后期Web服務器繼續(xù)增加，它本身可能成為系統(tǒng)的瓶頸。

3.IP負載均衡

IP負載均衡服務是工作在網絡層（修改IP）和傳輸層（修改端口，第四層），比起工作在應用層（第七層）性能要高出非常多。原理是，他是對IP層的數(shù)據(jù)包的IP地址和端口信息進行修改，達到負載均衡的目的。這種方式，也被稱為“四層負載均衡”。常見的負載均衡方式，是LVS（LinuxVirtualServer，Linux虛擬服務），通過IPVS（IPVirtualServer，IP虛擬服務）來實現(xiàn)。

在負載均衡服務器收到客戶端的IP包的時候，會修改IP包的目標IP地址或端口，然后原封不動地投遞到內部網絡中，數(shù)據(jù)包會流入到實際Web服務器。實際服務器處理完成后，又會將數(shù)據(jù)包投遞回給負載均衡服務器，它再修改目標IP地址為用戶IP地址，最終回到客戶端。

上述的方式叫LVS-NaT，除此之外，還有LVS-RD（直接路由），LVS-TUN（IP隧道），三者之間都屬于LVS的方式，但是有一定的區(qū)別，篇幅問題，不贅敘。

IP負載均衡的性能要高出Nginx的反向代理很多，它只處理到傳輸層為止的數(shù)據(jù)包，并不做進一步的組包，然后直接轉發(fā)給實際服務器。不過，它的配置和搭建比較復雜。

4.DNS負載均衡

DNS（DomainNameSystem）負責域名解析的服務，域名url實際上是服務器的別名，實際映射是一個IP地址，解析過程，就是DNS完成域名到IP的映射。而一個域名是可以配置成對應多個IP的。因此，DNS也就可以作為負載均衡服務。

這種負載均衡策略，配置簡單，性能極佳。但是，不能自由定義規(guī)則，而且，變更被映射的IP或者機器故障時很麻煩，還存在DNS生效延遲的問題。

5.DNS/GSLB負載均衡

我們常用的CDN（ContentDeliveryNetwork，內容分發(fā)網絡）實現(xiàn)方式，其實就是在同一個域名映射為多IP的基礎上更進一步，通過GSLB（GlobalServerLoadBalance，全局負載均衡）按照指定規(guī)則映射域名的IP。一般情況下都是按照地理位置，將離用戶近的IP返回給用戶，減少網絡傳輸中的路由節(jié)點之間的跳躍消耗。

實際過程是LDNS（LocalDNS）先向根域名服務（RootNameServer）獲取到頂級根的NameServer（例如.com的），然后得到指定域名的授權DNS，然后再獲得實際服務器IP。

CDN在Web系統(tǒng)中，一般情況下是用來解決大小較大的靜態(tài)資源（html/Js/Css/圖片等）的加載問題，讓這些比較依賴網絡下載的內容，盡可能離用戶更近，提升用戶體驗。

例如，我訪問了一張imgcache.gtimg.cn上的圖片（騰訊的自建CDN，不使用qq.com域名的原因是防止http請求的時候，帶上了多余的cookie信息），我獲得的IP是183.60.217.90。

網站標題：公司網站制作的負載均衡解決方案
本文URL：http://m.2m8n56k.cn/news/140895.html

網站建設、網絡推廣公司-創(chuàng)新互聯(lián)，是專注品牌與效果的網站制作，網絡營銷seo公司；服務項目有網站制作、解決方案等

廣告

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