Web負載均衡

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

當單機容量達到極限時,我們需要考慮業務拆分和分佈式部署,來解決大型網站訪問量大,併發量高,海量數據的問題。從單機到分佈式,很重要的區別是業務拆分和分佈式部署,將應用拆分後,部署到不同的機器上,實現大規模分佈式系統。分佈式和業務拆分解決了,從集中到分佈的問題,但是每個部署的獨立業務還存在單點的問題和訪問統一入口問題,為解決單點故障,我們可以採取冗餘的方式。將相同的應用部署到多臺機器上。解決訪問統一入口問題,我們可以在集群前面增加負載均衡設備,實現流量分發。

Web負載均衡(Load Balancing),簡單地說就是將負載(工作任務,訪問請求)進行平衡、分攤到多個操作單元(服務器,組件)上進行執行。對於保護處於後端的Web服務器來說,非常重要,是解決高性能,單點故障(高可用),擴展性(水平伸縮)的終極解決方案。


Web負載均衡

負載均衡的策略有很多,我們從簡單的講起哈。

HTTP負載均衡

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


Web負載均衡

如果使用PHP代碼來實現這個功能,方式如下:


Web負載均衡

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

反向代理負載均衡

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


Web負載均衡

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

解決方案主要有兩種:

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

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

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

IP負載均衡

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


Web負載均衡

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


Web負載均衡

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

IP負載均衡的性能要高出Nginx的反向代理很多,它只處理到傳輸層為止的數據包,並不做進一步的組包,然後直接轉發給實際服務器。不過,它的配置和搭建比較複雜。

DNS負載均衡

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


Web負載均衡

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

DNS/GSLB負載均衡

我們常用的CDN(Content Delivery Network,內容分發網絡)實現方式,其實就是在同一個域名映射為多IP的基礎上更進一步,通過GSLB(Global Server Load Balance,全局負載均衡)按照指定規則映射域名的IP。一般情況下都是按照地理位置,將離用戶近的IP返回給用戶,減少網絡傳輸中的路由節點之間的跳躍消耗。


Web負載均衡

圖中的“向上尋找”,實際過程是LDNS(Local DNS)先向根域名服務(Root Name Server)獲取到頂級根的Name Server(例如.com的),然後得到指定域名的授權DNS,然後再獲得實際服務器IP。


Web負載均衡

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

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


Web負載均衡

這種方式,和前面的DNS負載均衡一樣,不僅性能極佳,而且支持配置多種策略。但是,搭建和維護成本非常高。互聯網一線公司,會自建CDN服務,中小型公司一般使用第三方提供的CDN。

負載均衡就總結到這,下篇會總結web系統緩存機制的建立和優化。


分享到:


相關文章: