掃二維碼與項目經(jīng)理溝通
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
作者:張松然 2019-07-31 09:04:42
云計算
虛擬化 當(dāng)前大多數(shù)的互聯(lián)網(wǎng)系統(tǒng)都使用了服務(wù)器集群技術(shù),集群是將相同服務(wù)部署在多臺服務(wù)器上構(gòu)成一個集群整體對外提供服務(wù)。

袁州網(wǎng)站制作公司哪家好,找成都創(chuàng)新互聯(lián)!從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項目制作,到程序開發(fā),運營維護。成都創(chuàng)新互聯(lián)成立于2013年到現(xiàn)在10年的時間,我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗,來保證我們的工作的順利進行。專注于網(wǎng)站建設(shè)就選成都創(chuàng)新互聯(lián)。
當(dāng)前大多數(shù)的互聯(lián)網(wǎng)系統(tǒng)都使用了服務(wù)器集群技術(shù),集群是將相同服務(wù)部署在多臺服務(wù)器上構(gòu)成一個集群整體對外提供服務(wù)。
圖片來自 Unsplash
這些集群可以是 Web 應(yīng)用服務(wù)器集群,也可以是數(shù)據(jù)庫服務(wù)器集群,還可以是分布式緩存服務(wù)器集群等等。
在實際應(yīng)用中,在 Web 服務(wù)器集群之前總會有一臺負載均衡服務(wù)器,負載均衡設(shè)備的任務(wù)就是作為 Web 服務(wù)器流量的入口,挑選最合適的一臺 Web 服務(wù)器,將客戶端的請求轉(zhuǎn)發(fā)給它處理,實現(xiàn)客戶端到真實服務(wù)端的透明轉(zhuǎn)發(fā)。
最近幾年很火的云計算以及分布式架構(gòu),本質(zhì)上也是將后端服務(wù)器作為計算資源、存儲資源,由某臺管理服務(wù)器封裝成一個服務(wù)對外提供,客戶端不需要關(guān)心真正提供服務(wù)的是哪臺機器。
在它看來,就好像它面對的是一臺擁有近乎無限能力的服務(wù)器,而本質(zhì)上,真正提供服務(wù)的,是后端的集群。
LVS、Nginx、HAProxy 是目前使用很廣泛的三種軟件負載均衡軟件。一般對負載均衡的使用是隨著網(wǎng)站規(guī)模的提升根據(jù)不同的階段來使用不同的技術(shù)。
具體的應(yīng)用需求還得具體分析,如果是中小型的 Web 應(yīng)用,比如日 PV 小于 1000 萬,用 Nginx 就完全可以了。
如果機器不少,可以用 DNS 輪詢,LVS 所耗費的機器還是比較多的;大型網(wǎng)站或重要的服務(wù),且服務(wù)器比較多時,可以考慮用 LVS。
目前關(guān)于網(wǎng)站架構(gòu)一般比較合理流行的架構(gòu)方案:
LVS
LVS 是 Linux Virtual Server 的簡稱,也就是 Linux 虛擬服務(wù)器?,F(xiàn)在 LVS 已經(jīng)是 Linux 標(biāo)準(zhǔn)內(nèi)核的一部分。
從 Linux 2.4 內(nèi)核以后,已經(jīng)完全內(nèi)置了 LVS 的各個功能模塊,無需給內(nèi)核打任何補丁,可以直接使用 LVS 提供的各種功能。
LVS 自從 1998 年開始,發(fā)展到現(xiàn)在已經(jīng)是一個比較成熟的技術(shù)項目了。
LVS 的體系結(jié)構(gòu):
LVS 架設(shè)的服務(wù)器集群系統(tǒng)由三個部分組成:
LVS 負載均衡機制
LVS 不像 HAProxy 等七層軟負載面向的是 HTTP 包,所以七層負載可以做的 URL 解析等工作,LVS 無法完成。
LVS 是四層負載均衡,也就是說建立在 OSI 模型的第四層,傳輸層之上,傳輸層上有我們熟悉的 TCP/UDP,LVS 支持 TCP/UDP 的負載均衡。
因為 LVS 是四層負載均衡,因此它相對于其它高層負載均衡的解決辦法,比如 DNS 域名輪流解析、應(yīng)用層負載的調(diào)度、客戶端的調(diào)度等,它的效率是非常高的。
所謂四層負載均衡 ,也就是主要通過報文中的目標(biāo)地址和端口。七層負載均衡 ,也稱為“內(nèi)容交換”,也就是主要通過報文中的真正有意義的應(yīng)用層內(nèi)容。
LVS 的轉(zhuǎn)發(fā)主要通過修改 IP 地址(NAT 模式,分為源地址修改 SNAT 和目標(biāo)地址修改 DNAT)、修改目標(biāo) MAC(DR 模式)來實現(xiàn)。
NAT 模式:網(wǎng)絡(luò)地址轉(zhuǎn)換
NAT(Network Address Translation)是一種外網(wǎng)和內(nèi)網(wǎng)地址映射的技術(shù)。
NAT 模式下,網(wǎng)絡(luò)數(shù)據(jù)報的進出都要經(jīng)過 LVS 的處理。LVS 需要作為 RS(真實服務(wù)器)的網(wǎng)關(guān)。
當(dāng)包到達 LVS 時,LVS 做目標(biāo)地址轉(zhuǎn)換(DNAT),將目標(biāo) IP 改為 RS 的 IP。
RS 接收到包以后,仿佛是客戶端直接發(fā)給它的一樣。RS 處理完,返回響應(yīng)時,源 IP 是 RS IP,目標(biāo) IP 是客戶端的 IP。
這時 RS 的包通過網(wǎng)關(guān)(LVS)中轉(zhuǎn),LVS 會做源地址轉(zhuǎn)換(SNAT),將包的源地址改為 VIP,這樣,這個包對客戶端看起來就仿佛是 LVS 直接返回給它的。
DR 模式:直接路由
DR 模式下需要 LVS 和 RS 集群綁定同一個 VIP(RS 通過將 VIP 綁定在 loopback 實現(xiàn))。
但與 NAT 的不同點在于:請求由 LVS 接受,由真實提供服務(wù)的服務(wù)器(RealServer,RS)直接返回給用戶,返回的時候不經(jīng)過 LVS。
詳細來看,一個請求過來時,LVS 只需要將網(wǎng)絡(luò)幀的 MAC 地址修改為某一臺 RS 的 MAC,該包就會被轉(zhuǎn)發(fā)到相應(yīng)的 RS 處理,注意此時的源 IP 和目標(biāo) IP 都沒變,LVS 只是做了一下移花接木。
RS 收到 LVS 轉(zhuǎn)發(fā)來的包時,鏈路層發(fā)現(xiàn) MAC 是自己的,到上面的網(wǎng)絡(luò)層,發(fā)現(xiàn) IP 也是自己的,于是這個包被合法地接受,RS 感知不到前面有 LVS 的存在。
而當(dāng) RS 返回響應(yīng)時,只要直接向源 IP(即用戶的 IP)返回即可,不再經(jīng)過 LVS。
DR 負載均衡模式數(shù)據(jù)分發(fā)過程中不修改 IP 地址,只修改 Mac 地址,由于實際處理請求的真實物理 IP 地址和數(shù)據(jù)請求目的 IP 地址一致,所以不需要通過負載均衡服務(wù)器進行地址轉(zhuǎn)換。
可將響應(yīng)數(shù)據(jù)包直接返回給用戶瀏覽器,避免負載均衡服務(wù)器網(wǎng)卡帶寬成為瓶頸。
因此,DR 模式具有較好的性能,也是目前大型網(wǎng)站使用廣泛的一種負載均衡手段。
LVS 的優(yōu)點如下:
LVS 的缺點如下:
Nginx
Nginx 是一個強大的 Web 服務(wù)器軟件,用于處理高并發(fā)的 HTTP 請求和作為反向代理服務(wù)器做負載均衡。
它具有高性能、輕量級、內(nèi)存消耗少,強大的負載均衡能力等優(yōu)勢。
Nignx 的架構(gòu)設(shè)計
相對于傳統(tǒng)基于進程或線程的模型(Apache 就采用這種模型)在處理并發(fā)連接時會為每一個連接建立一個單獨的進程或線程,且在網(wǎng)絡(luò)或者輸入/輸出操作時阻塞。
這將導(dǎo)致內(nèi)存和 CPU 的大量消耗,因為新起一個單獨的進程或線程需要準(zhǔn)備新的運行時環(huán)境,包括堆和棧內(nèi)存的分配,以及新的執(zhí)行上下文,當(dāng)然,這些也會導(dǎo)致多余的 CPU 開銷。
最終,會由于過多的上下文切換而導(dǎo)致服務(wù)器性能變差。反過來,Nginx 的架構(gòu)設(shè)計是采用模塊化的、基于事件驅(qū)動、異步、單線程且非阻塞。
Nginx 大量使用多路復(fù)用和事件通知,Nginx 啟動以后,會在系統(tǒng)中以 Daemon 的方式在后臺運行,其中包括一個 Master 進程,n(n>=1) 個 Worker 進程。
所有的進程都是單線程(即只有一個主線程)的,且進程間通信主要使用共享內(nèi)存的方式。
其中,Master 進程用于接收來自外界的信號,并給 Worker 進程發(fā)送信號,同時監(jiān)控 Worker 進程的工作狀態(tài)。
Worker 進程則是外部請求真正的處理者,每個 Worker 請求相互獨立且平等的競爭來自客戶端的請求。
請求只能在一個 Worker 進程中被處理,且一個 Worker 進程只有一個主線程,所以同時只能處理一個請求。(原理同 Netty 很像)
Nginx 負載均衡
Nginx 負載均衡主要是對七層網(wǎng)絡(luò)通信模型中的第七層應(yīng)用層上的 HTTP、HTTPS 進行支持。Nginx 是以反向代理的方式進行負載均衡的。
反向代理(Reverse Proxy)方式是指以代理服務(wù)器來接受 Internet 上的連接請求,然后將請求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器,并將從服務(wù)器上得到的結(jié)果返回給 Internet 上請求連接的客戶端,此時代理服務(wù)器對外就表現(xiàn)為一個服務(wù)器。
Nginx 實現(xiàn)負載均衡的分配策略有很多,Nginx 的 Upstream 目前支持以下幾種方式:
Nginx 的優(yōu)點如下:
Nginx 的缺點如下:
HAProxy
HAProxy 支持兩種代理模式 TCP(四層)和 HTTP(七層),也是支持虛擬主機的。
HAProxy 的優(yōu)點能夠補充 Nginx 的一些缺點,比如支持 Session 的保持,Cookie 的引導(dǎo);同時支持通過獲取指定的 URL 來檢測后端服務(wù)器的狀態(tài)。
HAProxy 跟 LVS 類似,本身就只是一款負載均衡軟件;單純從效率上來講 HAProxy 會比 Nginx 有更出色的負載均衡速度,在并發(fā)處理上也是優(yōu)于 Nginx 的。
HAProxy 支持 TCP 協(xié)議的負載均衡轉(zhuǎn)發(fā),可以對 MySQL 讀進行負載均衡,對后端的 MySQL 節(jié)點進行檢測和負載均衡,大家可以用 LVS+Keepalived 對 MySQL 主從做負載均衡。
HAProxy 負載均衡策略非常多:
Reference:

我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流