當一個Web系統從日訪問量10萬逐步增長到1000萬,甚至超過1億的過程中,Web系統承受的壓力會越來越大,在這個過程中,我們會遇到很多的問題。為瞭解決這些性能壓力帶來問題,我們需要在Web系統架構層面搭建多個層次的緩存機制。在不同的壓力階段,我們會遇到不同的問題,通過搭建不同的服務和架構來解決。 ...
當一個Web系統從日訪問量10萬逐步增長到1000萬,甚至超過1億的過程中,Web系統承受的壓力會越來越大,在這個過程中,我們會遇到很多的問題。為瞭解決這些性能壓力帶來問題,我們需要在Web系統架構層面搭建多個層次的緩存機制。在不同的壓力階段,我們會遇到不同的問題,通過搭建不同的服務和架構來解決。
Web負載均衡
Web負載均衡(Load Balancing),簡單地說就是給我們的伺服器集群分配“工作任務”,而採用恰當的分配方式,對於保護處於後端的Web伺服器來說,非常重要。
負載均衡的策略有很多,我們從簡單的講起哈。
1. HTTP重定向
當用戶發來請求的時候,Web伺服器通過修改HTTP響應頭中的Location標記來返回一個新的url,然後瀏覽器再繼續請求這個新url,實際上就是頁面重定向。通過重定向,來達到“負載均衡”的目標。例如,我們在下載PHP源碼包的時候,點擊下載鏈接時,為瞭解決不同國家和地域下載速度的問題,它會返回一個離我們近的下載地址。重定向的HTTP返回碼是302,如下圖:
如果使用PHP代碼來實現這個功能,方式如下:
這個重定向非常容易實現,並且可以自定義各種策略。但是,它在大規模訪問量下,性能不佳。而且,給用戶的體驗也不好,實際請求發生重定向,增加了網路延時。
2. 反向代理負載均衡
反向代理服務的核心工作主要是轉發HTTP請求,扮演了瀏覽器端和後臺Web伺服器中轉的角色。因為它工作在HTTP層(應用層),也就是網路七層結構中的第七層,因此也被稱為“七層負載均衡”。可以做反向代理的軟體很多,比較常見的一種是Nginx。
Nginx是一種非常靈活的反向代理軟體,可以自由定製化轉發策略,分配伺服器流量的權重等。反向代理中,常見的一個問題,就是Web伺服器存儲的session數據,因為一般負載均衡的策略都是隨機分配請求的。同一個登錄用戶的請求,無法保證一定分配到相同的Web機器上,會導致無法找到session的問題。
解決方案主要有兩種:
- 配置反向代理的轉發規則,讓同一個用戶的請求一定落到同一臺機器上(通過分析cookie),複雜的轉發規則將會消耗更多的CPU,也增加了代理伺服器的負擔。
- 將session這類的信息,專門用某個獨立服務來存儲,例如redis/memchache,這個方案是比較推薦的。
反向代理服務,也是可以開啟緩存的,如果開啟了,會增加反向代理的負擔,需要謹慎使用。這種負載均衡策略實現和部署非常簡單,而且性能表現也比較好。但是,它有“單點故障”的問題,如果掛了,會帶來很多的麻煩。而且,到了後期Web伺服器繼續增加,它本身可能成為系統的瓶頸。
3. IP負載均衡
IP負載均衡服務是工作在網路層(修改IP)和傳輸層(修改埠,第四層),比起工作在應用層(第七層)性能要高出非常多。原理是,他是對IP層的數據包的IP地址和埠信息進行修改,達到負載均衡的目的。這種方式,也被稱為“四層負載均衡”。常見的負載均衡方式,是LVS(Linux Virtual Server,Linux虛擬服務),通過IPVS(IP Virtual Server,IP虛擬服務)來實現。
在負載均衡伺服器收到客戶端的IP包的時候,會修改IP包的目標IP地址或埠,然後原封不動地投遞到內部網路中,數據包會流入到實際Web伺服器。實際伺服器處理完成後,又會將數據包投遞迴給負載均衡伺服器,它再修改目標IP地址為用戶IP地址,最終回到客戶端。
上述的方式叫LVS-NAT,除此之外,還有LVS-RD(直接路由),LVS-TUN(IP隧道),三者之間都屬於LVS的方式,但是有一定的區別,篇幅問題,不贅敘。
IP負載均衡的性能要高出Nginx的反向代理很多,它只處理到傳輸層為止的數據包,並不做進一步的組包,然後直接轉發給實際伺服器。不過,它的配置和搭建比較複雜。
4. DNS負載均衡
DNS(Domain Name System)負責功能變數名稱解析的服務,功能變數名稱url實際上是伺服器的別名,實際映射是一個IP地址,解析過程,就是DNS完成功能變數名稱到IP的映射。而一個功能變數名稱是可以配置成對應多個IP的。因此,DNS也就可以作為負載均衡服務。
這種負載均衡策略,配置簡單,性能極佳。但是,不能自由定義規則,而且,變更被映射的IP或者機器故障時很麻煩,還存在DNS生效延遲的問題。
5. DNS/GSLB負載均衡
我們常用的CDN(Content Delivery Network,內容分髮網絡)實現方式,其實就是在同一個功能變數名稱映射為多IP的基礎上更進一步,通過GSLB(Global Server Load Balance,全局負載均衡)按照指定規則映射功能變數名稱的IP。一般情況下都是按照地理位置,將離用戶近的IP返回給用戶,減少網路傳輸中的路由節點之間的跳躍消耗。
圖中的“向上尋找”,實際過程是LDNS(Local DNS)先向根功能變數名稱服務(Root Name Server)獲取到頂級根的Name Server(例如.com的),然後得到指定功能變數名稱的授權DNS,然後再獲得實際伺服器IP。
CDN在Web系統中,一般情況下是用來解決大小較大的靜態資源(html/Js/Css/圖片等)的載入問題,讓這些比較依賴網路下載的內容,儘可能離用戶更近,提升用戶體驗。
例如,我訪問了一張imgcache.gtimg.cn上的圖片(騰訊的自建CDN,不使用qq.com功能變數名稱的原因是防止http請求的時候,帶上了多餘的cookie信息),我獲得的IP是183.60.217.90。
這種方式,和前面的DNS負載均衡一樣,不僅性能極佳,而且支持配置多種策略。但是,搭建和維護成本非常高。互聯網一線公司,會自建CDN服務,中小型公司一般使用第三方提供的CDN。