基于Nginx負(fù)載均衡架構(gòu)的云計(jì)算分布式系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

彭好佑，符天，楊登攀，傅翠玉，姚堅(jiān)

（海南軟件職業(yè)技術(shù)學(xué)院，海南 瓊海 571400)

0 引言

隨著信息技術(shù)的高速發(fā)展，互聯(lián)網(wǎng)用戶也得到巨大的增長(zhǎng)，爆發(fā)式的高并發(fā)訪問請(qǐng)求給單一的服務(wù)器帶來嚴(yán)峻的挑戰(zhàn)，準(zhǔn)確及時(shí)地響應(yīng)高并發(fā)的訪問請(qǐng)求，是云計(jì)算分布式系統(tǒng)一個(gè)重要的研究熱點(diǎn)。架構(gòu)相應(yīng)的云計(jì)算分布式服務(wù)系統(tǒng)并實(shí)現(xiàn)高質(zhì)量的負(fù)載均衡，是提高云計(jì)算服務(wù)的響應(yīng)質(zhì)量重要方式之一。

負(fù)載均衡是云計(jì)算分布式應(yīng)用系統(tǒng)中最核心的技術(shù)之一。云計(jì)算分布式系統(tǒng)負(fù)載均衡最主要目的是通過相應(yīng)分發(fā)策略，將用戶的并發(fā)請(qǐng)求通過分配策略平均分配給云計(jì)算的服務(wù)節(jié)點(diǎn)，使服務(wù)節(jié)點(diǎn)的平均請(qǐng)求響應(yīng)時(shí)間最少，吞吐量最大，資源得到最充分的利用,避免某服務(wù)節(jié)點(diǎn)過載的目的[1]。在云計(jì)算分布式系統(tǒng)中，如果只是單一增加服務(wù)器數(shù)量，不采用適應(yīng)負(fù)載均衡技術(shù)，將會(huì)導(dǎo)致有些服務(wù)屬于超負(fù)載運(yùn)轉(zhuǎn)狀態(tài)，甚至?xí)霈F(xiàn)系統(tǒng)崩潰，而有些服務(wù)器卻處于空閑的狀態(tài)，影響云計(jì)算分布式系統(tǒng)服務(wù)質(zhì)量，用戶體驗(yàn)較差，系統(tǒng)資源利用率較低。因此，負(fù)載均衡算法的轉(zhuǎn)發(fā)策略影響整個(gè)云計(jì)算分布式系統(tǒng)的服務(wù)質(zhì)量，采用合適的負(fù)載均衡器是云計(jì)算分布式系統(tǒng)考慮核心問題。Nginx是一個(gè)高性能的基于七層負(fù)載均衡的反向代理Web 服務(wù)器，具有穩(wěn)定強(qiáng)、高并發(fā)、低消耗、安全性高，配置簡(jiǎn)單靈活的特點(diǎn)[2]，比較適合作為云計(jì)算分布式系統(tǒng)的負(fù)載均衡器。

本論文通過對(duì)負(fù)載均衡算法進(jìn)行研究分析，采用Nginx 負(fù)載均衡器高響應(yīng)并發(fā)請(qǐng)求，設(shè)計(jì)并搭建云計(jì)算分布式系統(tǒng)和監(jiān)控模型，在高并發(fā)訪問中實(shí)現(xiàn)負(fù)載均衡，提高云計(jì)算分布式系統(tǒng)的可靠性和穩(wěn)定性。

1 負(fù)載均衡算法

負(fù)載均衡算法是負(fù)載均衡器的核心部分，負(fù)載均衡器根據(jù)負(fù)載均衡算法將用戶并發(fā)請(qǐng)求平均分配到不同的服務(wù)器，在有限的系統(tǒng)資源中，實(shí)現(xiàn)資源利用的最大化。

1.1 負(fù)載均衡算法分類

目前常見的負(fù)載均衡算法主要有：

1) 硬件負(fù)載均衡。從專門的硬件設(shè)備上實(shí)現(xiàn)負(fù)載均衡功能[3]，與系統(tǒng)無關(guān)，該設(shè)備具有負(fù)載均衡能力強(qiáng)，能使整個(gè)分布式系統(tǒng)達(dá)到最佳的性能，但缺點(diǎn)是設(shè)備價(jià)格昂貴，成本高。

2) 軟件負(fù)載均衡。將軟件安裝某硬件上作為負(fù)載均衡器[4]，通過軟件來實(shí)現(xiàn)系統(tǒng)性能達(dá)到最佳的效果，軟件負(fù)載均衡器優(yōu)點(diǎn)是配置靈活，具有各種請(qǐng)求調(diào)度算法，成本比較廉價(jià)。缺點(diǎn)是安裝和運(yùn)行負(fù)載均衡軟件需要消耗計(jì)算機(jī)系統(tǒng)的額外開銷，很容易成為系統(tǒng)的性能瓶頸。

1.2 Nginx內(nèi)置均衡算法

Nginx 基于軟件負(fù)載均衡算法，其負(fù)載均衡策略主要分兩種：內(nèi)置負(fù)載均衡策略和擴(kuò)展負(fù)載均衡策略。內(nèi)置的負(fù)載均衡算法主要有：加權(quán)算法、輪詢算法、IP_hash 算法、fare 和url_hash 算法。外置的算法是根據(jù)需求，開發(fā)人員自己編寫的負(fù)載均衡算法。

1) 輪詢算法

該算法根據(jù)預(yù)先設(shè)定好的某種固定順序，按順序周期響應(yīng)服務(wù)請(qǐng)求，當(dāng)負(fù)載均衡器收到用戶請(qǐng)求后，按照預(yù)先制定輪詢分配方案，當(dāng)一個(gè)周期結(jié)束，按原來固定順序開始新的周期分配給不同的服務(wù)節(jié)點(diǎn)。

2) 加權(quán)輪詢算法

加權(quán)輪詢算法根據(jù)設(shè)定好的權(quán)重，根據(jù)服務(wù)節(jié)點(diǎn)權(quán)重的大小，選擇權(quán)重最大的節(jié)點(diǎn)，選中該節(jié)點(diǎn)后，該節(jié)點(diǎn)的權(quán)重自動(dòng)減1，并重新進(jìn)行排序，重復(fù)以上步驟，根據(jù)權(quán)重來分發(fā)請(qǐng)求到不同的服務(wù)節(jié)點(diǎn)中，權(quán)重weight 和訪問比率成正比，用于后端服務(wù)器性能不均的情況。

3) IP hash算法

根據(jù)hash 算法將請(qǐng)求訪問服務(wù)器的IP 放入一張hash 表中[5]，即根據(jù)IP 地址進(jìn)行hash 散列算法找到其相應(yīng)的后端服務(wù)器，把客戶端的請(qǐng)求分配該服務(wù)器。該算法主要優(yōu)點(diǎn)是相同IP 地址將被分配到同一臺(tái)后端服務(wù)器，這種算法用于有狀態(tài)session 會(huì)話應(yīng)用場(chǎng)景[6]。

4) url_hash 算法

按訪問url 的hash 結(jié)果來分配請(qǐng)求，使每個(gè)url 定向到同一個(gè)后端服務(wù)器，這種算法在后端服務(wù)器為緩存時(shí)比較有效。

5) fair 算法

按后端服務(wù)器的響應(yīng)時(shí)間來分配請(qǐng)求，響應(yīng)時(shí)間短的服務(wù)器優(yōu)先分配[5]。這種算法適用于對(duì)訪問性能要求較高的業(yè)務(wù)應(yīng)用，是一種更為智能的負(fù)載均衡算法。

2 云計(jì)算分布式系統(tǒng)的設(shè)計(jì)

云計(jì)算分布式系統(tǒng)架構(gòu)的設(shè)計(jì)方案如圖1 所示，采用Nginx 中間件作為負(fù)載均衡器，實(shí)現(xiàn)云計(jì)算分布式系統(tǒng)在高并發(fā)訪問請(qǐng)求中負(fù)載均衡。Nginx負(fù)載均衡器通過的負(fù)載均衡算法把客戶端的用戶請(qǐng)求分配給適合后端Web服務(wù)器，后端Web服務(wù)器響應(yīng)用戶的請(qǐng)求，把請(qǐng)求結(jié)果返回客戶端用戶，實(shí)現(xiàn)負(fù)載均衡。在該架構(gòu)中，監(jiān)控服務(wù)器定時(shí)收集后端Web服務(wù)器和Nginx負(fù)載均衡器性能信息，監(jiān)控其運(yùn)行狀態(tài)、負(fù)載情況，超過設(shè)定負(fù)載可發(fā)出警告信息，便于及時(shí)發(fā)現(xiàn)問題和維護(hù)。

圖1 云計(jì)算分布式系統(tǒng)架構(gòu)

監(jiān)控系統(tǒng)的設(shè)計(jì)。Prometheus是一款開源的監(jiān)控系統(tǒng)，具備對(duì)Kubernetes管理的容器云的監(jiān)控功能，可對(duì)容器云上的Node物理節(jié)點(diǎn)、應(yīng)用容器、Kubernetes集群資源、容器應(yīng)用運(yùn)行狀態(tài)進(jìn)行動(dòng)態(tài)發(fā)現(xiàn)、監(jiān)控和智能告警[7]。Grafana是一個(gè)開源的度量分析和可視化工具，可將采集的數(shù)據(jù)進(jìn)行分析和查詢，最后實(shí)現(xiàn)可視化的展示和過載報(bào)警[8]。如圖2所示，云計(jì)算分布式系統(tǒng)監(jiān)控方案采用Prometheus和Grafana 建立監(jiān)控系統(tǒng)，分為數(shù)據(jù)收集、數(shù)據(jù)提取和數(shù)據(jù)展示三部分。在數(shù)據(jù)收集端的Web服務(wù)器中采用Node_exporter 監(jiān)控工具，將被采集的數(shù)據(jù)信息通過HTTP服務(wù)的方式發(fā)給監(jiān)控服務(wù)器Prometheus Server。在數(shù)據(jù)提取模塊，監(jiān)控服務(wù)器Prometheus Server 負(fù)責(zé)獲取、查詢和保存被監(jiān)控端的信息，將收集到監(jiān)控端的數(shù)據(jù)保存到時(shí)序數(shù)據(jù)庫(Time Series Database，TSDB) 。數(shù)據(jù)展示端通過Grafana軟件實(shí)現(xiàn)可視化業(yè)務(wù)系統(tǒng)監(jiān)控展示和過載警告信息的輸出。

圖2 監(jiān)控系統(tǒng)模型

云計(jì)算分布式系統(tǒng)仿真平臺(tái)搭建需求如表1 所示，其中4 臺(tái)PC 機(jī)都在VMware Workstation 部署centos 7.6 操作系統(tǒng)，負(fù)載均衡采用Nginx實(shí)現(xiàn)，Web01和Web02 是部署PHP 和MySQL 的Web 服務(wù)器。客戶端為Win 10 操作系統(tǒng)PC 機(jī)，采用Apache Bench 工具模擬高并發(fā)訪問請(qǐng)求，測(cè)試云計(jì)算分布式系統(tǒng)性能，這5臺(tái)PC 通過網(wǎng)線連接在同一個(gè)交換機(jī)上。Prometheus Server實(shí)時(shí)采集Web01、Web02和Nginx負(fù)載均衡器的運(yùn)行信息和負(fù)載情況，為云計(jì)算分布式系統(tǒng)的性能分析提供依據(jù)。

表1 10組并發(fā)總數(shù)4000個(gè)并發(fā)數(shù)500個(gè)高并發(fā)訪問請(qǐng)求測(cè)試

3 云計(jì)算分布式系統(tǒng)的實(shí)現(xiàn)

Web01 和Web02 中安裝Nginx 和MySQL，在Web01 和Web02 中修改nginx.conf，將Nginx 關(guān)聯(lián)PHP服務(wù)，完成的Web 服務(wù)器搭建。編寫測(cè)試腳本test.php，查詢數(shù)據(jù)庫test 中的mobile 表中數(shù)據(jù)，并把查詢到的數(shù)據(jù)返回到Web頁面。

3.1 加權(quán)輪詢算法

負(fù)載均衡器采用加權(quán)算法，根據(jù)服務(wù)器性能內(nèi)存、CPU 等情況分配相應(yīng)的權(quán)重，Web01 設(shè)置權(quán)重值為1，Web02 設(shè)置權(quán)重值為2。Nginx 負(fù)載均衡器當(dāng)檢測(cè)到Web服務(wù)器連接異常時(shí)，在timeout周期內(nèi)，Nginx將請(qǐng)求發(fā)送給可用的服務(wù)節(jié)點(diǎn)，在Nginx 負(fù)載均衡器修改配置代碼：

3.2 監(jiān)控系統(tǒng)部署

1) node_exporter的安裝

Web01、Web02 和Nginx 負(fù)載均衡器中安裝Node_exporter 組件工具，并啟動(dòng)node_exporter 收集服務(wù)器信息。

2) 在監(jiān)控服務(wù)器中安裝prometheus server，在Prometheus.yml 文件中，增加需要抓取的節(jié)點(diǎn)的信息，啟動(dòng)prometheus server 抓取Web01、Web02 和Nginx 負(fù)載均衡器運(yùn)行信息。

修改Prometheus.yml，增加以下代碼

3) 安裝和啟動(dòng)Grafana 服務(wù)，通過http://192.168.40.13:3000 登錄Grafana，加載數(shù)據(jù)源，加載Dashboard監(jiān)控模塊，查看Web01、Web02和nginx負(fù)載均衡器運(yùn)行信息。

3.3 實(shí)驗(yàn)測(cè)試

客戶端使用Apache 的Apache Bench 工具向服務(wù)器端發(fā)送高并發(fā)連接訪問請(qǐng)求，發(fā)送請(qǐng)求總是分別4000、4500、5000、5500、6000、6500、7000、7500、8000個(gè)高并發(fā)請(qǐng)求，同時(shí)并發(fā)數(shù)500 個(gè)。對(duì)單一服務(wù)器Web01 提供請(qǐng)求響應(yīng)，當(dāng)在并發(fā)總數(shù)是5000 個(gè)時(shí)，開始出現(xiàn)丟包現(xiàn)象，丟包數(shù)為2個(gè)；而云計(jì)算分布式系統(tǒng)在4 000～8 000 個(gè)的高并發(fā)訪問時(shí)，并無丟包情況。如圖3 所示，單獨(dú)服務(wù)器Web01 響應(yīng)高并發(fā)請(qǐng)求時(shí)，隨著請(qǐng)求總數(shù)的增加，CPU 的使用率越來越高，增長(zhǎng)較快。而云計(jì)算分布式系統(tǒng)中Web01 和Web02 同時(shí)響應(yīng)高并發(fā)請(qǐng)求，其CPU使用率較低，且增長(zhǎng)較緩慢，實(shí)現(xiàn)了負(fù)載均衡。

圖3 高并發(fā)請(qǐng)求響應(yīng)時(shí)CPU使用率

并發(fā)請(qǐng)求連接總數(shù)分別為2100、2400、2700、3000、3300、3600、3900、4200、4500高并發(fā)訪問，并發(fā)連接500 個(gè)，模擬500 用戶在線同時(shí)HTTP 訪問，統(tǒng)計(jì)Web01和Web02 的TCP連接數(shù)。實(shí)驗(yàn)結(jié)果如圖4和圖5所示，經(jīng)過Nginx 進(jìn)行負(fù)載均衡后， Web01和Web02的TCP連接比例基本是1:2，實(shí)驗(yàn)表明根據(jù)后端服務(wù)器的性能實(shí)現(xiàn)加權(quán)輪詢算法分配策略的負(fù)載均衡。

表2 9組高并發(fā)數(shù)請(qǐng)求Web01和Web02的TCP_tw連接數(shù)

4 總結(jié)

本文根據(jù)云計(jì)算分布式系統(tǒng)在高并發(fā)訪問請(qǐng)求中存在的負(fù)載不均衡、響應(yīng)速度下降的問題，對(duì)負(fù)載均衡算法進(jìn)行研究，設(shè)計(jì)云計(jì)算分布式系統(tǒng)架構(gòu)，采用Nginx 負(fù)載均衡器架構(gòu)云計(jì)算分布式系統(tǒng)和采用Prometheus和Grafana建立監(jiān)控系統(tǒng)，監(jiān)控后端服務(wù)器運(yùn)行情況和超載預(yù)警。最后，對(duì)云計(jì)算分布式系統(tǒng)進(jìn)行高并發(fā)仿真測(cè)試，實(shí)驗(yàn)表明該云計(jì)算分布式系統(tǒng)比單一的服務(wù)器系統(tǒng)有較高的可靠性，較低的系統(tǒng)資源使用率，實(shí)現(xiàn)基于加權(quán)輪詢算法的負(fù)載均衡。