摘 ?要: 隨著信息時(shí)代的到來(lái)、互聯(lián)網(wǎng)技術(shù)的高速發(fā)展,隨之而來(lái)的不可避免的一個(gè)至關(guān)重要的問(wèn)題就是web系統(tǒng)性能的好壞。當(dāng)多個(gè)用戶(hù)同時(shí)訪問(wèn)同一個(gè)資源,當(dāng)同一時(shí)刻服務(wù)器接收到數(shù)以?xún)|計(jì)甚至更多的請(qǐng)求,引起的網(wǎng)路堵塞或者是服務(wù)超載會(huì)出現(xiàn)請(qǐng)求失敗、系統(tǒng)響應(yīng)緩慢,甚至?xí)?dǎo)致web網(wǎng)站的崩潰,這種高并發(fā)性問(wèn)題引起的后果是難以想象的。本文針對(duì)web系統(tǒng)的高并發(fā)業(yè)務(wù)處理方式之負(fù)載均衡方式進(jìn)行相對(duì)深入的研究,將對(duì)三種實(shí)現(xiàn)負(fù)載均衡的方式進(jìn)行詳解。可根據(jù)情況合情合理地選擇合適的負(fù)載均衡方式,以提高系統(tǒng)對(duì)高并發(fā)業(yè)務(wù)處理的響應(yīng)速度,提高系統(tǒng)的整體性能。本文對(duì)大型web系統(tǒng)的性能提高有一定的幫助作用。
關(guān)鍵詞: 負(fù)載均衡;高并發(fā)業(yè)務(wù)處理;Web性能
中圖分類(lèi)號(hào): TP302.7 ? ?文獻(xiàn)標(biāo)識(shí)碼: A ? ?DOI:10.3969/j.issn.1003-6970.2019.08.032
本文著錄格式:李潔. 基于web應(yīng)用的高并發(fā)業(yè)務(wù)處理研究之負(fù)載均衡[J]. 軟件,2019,40(8):136138
【Abstract】: With coming of the technology age and the rapid development of Internet technology, an unavoidable and crucial problem is the performance of web system. When multiple users access the same resource at the same time, when the server receives tens of thousands or more requests at the same time, the network congestion or service overload will result in request failure, slow system response, and even the collapse of the web site. The consequences of this high concurrency problem are unimaginable. In this paper, the load balancing of high concurrent service processing mode in web system is studied in depth, and three implementation methods of load balancing are introduced in detail. The appropriate load balancing mode can be reasonably selected according to the situation to improve the response speed of the system to high concurrent business processing and the overall performance of the system. This paper is helpful to improve the performance of large-scale web systems.
【Key words】: Load balancing; High concurrent business processing; Web performance
0 ?引言
隨著信息時(shí)代的到來(lái)、互聯(lián)網(wǎng)技術(shù)的快速發(fā)展,隨之而來(lái)的不可避免的一個(gè)至關(guān)重要的問(wèn)題就是web系統(tǒng)性能的好壞。系統(tǒng)性能是否優(yōu)良是用戶(hù)滿(mǎn)意度高不高的一個(gè)重要體現(xiàn)。就好比淘寶雙十一的搶購(gòu),看到頁(yè)面顯示的加載失敗或是稍后再試,用戶(hù)的心情是很絕望的;節(jié)假日車(chē)票發(fā)售時(shí),網(wǎng)上搶票購(gòu)票卻怎么也買(mǎi)不到的不易;各類(lèi)考試報(bào)名網(wǎng)站報(bào)名在高峰期運(yùn)行的差強(qiáng)人意。這些情況就用戶(hù)而言,體驗(yàn)感是極差的。而對(duì)web開(kāi)發(fā)者來(lái)講,這無(wú)疑也是web開(kāi)發(fā)者面臨的巨大的考驗(yàn)。當(dāng)多個(gè)用戶(hù)同時(shí)訪問(wèn)同一個(gè)資源,當(dāng)同一時(shí)刻服務(wù)器收到數(shù)以?xún)|計(jì)甚至更多的請(qǐng)求,引起的網(wǎng)路堵塞或者是服務(wù)超載會(huì)出現(xiàn)請(qǐng)求失敗、系統(tǒng)響應(yīng)緩慢,甚至?xí)?dǎo)致web網(wǎng)站的崩潰,這種高并發(fā)性問(wèn)題引起的后果是難以想象的。
我們對(duì)于這種web系統(tǒng)的整體性能優(yōu)化,能夠從硬件以及軟件兩大方面解決。人們可以通過(guò)在服務(wù)器和外部網(wǎng)絡(luò)直接安裝負(fù)載均衡器、提高硬件質(zhì)量、擴(kuò)大內(nèi)存、增加服務(wù)器的數(shù)量等多種方式來(lái)減輕服務(wù)器端的壓力,提高web站點(diǎn)的性能,但是很多情況下,這不但解決不了問(wèn)題,反而會(huì)導(dǎo)致資源無(wú)法被充分的利用,造成資源的浪費(fèi)。而且對(duì)于開(kāi)發(fā)者來(lái)說(shuō),經(jīng)濟(jì)成本也較為昂貴。舉個(gè)簡(jiǎn)單的例子,就比如一個(gè)人流量很少的地方一開(kāi)始交通不便,后來(lái)為了提供更好的服務(wù),通行了多趟公交車(chē),然而真實(shí)情況是在該地區(qū)運(yùn)行的每趟公交車(chē)很多情況下都坐不滿(mǎn),人很少,這就是一種對(duì)公交車(chē)資源的浪費(fèi)。再如圖1所示:當(dāng)請(qǐng)求1、請(qǐng)求2、請(qǐng)求3、請(qǐng)求4以及請(qǐng)求5都到達(dá)web服務(wù)器時(shí),web服務(wù)器將請(qǐng)求按類(lèi)型分發(fā)給子服務(wù)器0和子服務(wù)器1,由于請(qǐng)求分配的不均勻,子服務(wù)器2此刻便是閑暇狀態(tài)。這就是對(duì)資源的不充分利用。所以通過(guò)硬件的這種方式是有一定缺陷的。
那么由此可看出:當(dāng)一臺(tái)服務(wù)器的吞吐量到達(dá)最大值時(shí),可以通過(guò)應(yīng)用web服務(wù)器集群來(lái)優(yōu)化web站點(diǎn),對(duì)web系統(tǒng)整體性能進(jìn)行提升。所以在web服務(wù)器集群中,需要一個(gè)服務(wù)器作為調(diào)度者來(lái)接收用戶(hù)的所有請(qǐng)求,該服務(wù)器再按照實(shí)際情況下各個(gè)服務(wù)器的負(fù)載狀態(tài)依賴(lài)于某個(gè)具體的調(diào)度策略將用戶(hù)的請(qǐng)求合理分發(fā)到具體的后端服務(wù)器處理,從節(jié)點(diǎn)上減少單個(gè)服務(wù)器的負(fù)載,提升web站點(diǎn)的響應(yīng)能力[1]。
很明顯在該過(guò)程里,我們關(guān)注于服務(wù)器,也就是調(diào)度者該如何合理分發(fā)請(qǐng)求,以達(dá)到所有的后端服務(wù)器都能夠被充分使用,充分發(fā)揮其作用,使得web服務(wù)器集群的整體性能相對(duì)最高化,這就是要詳細(xì)說(shuō)明的問(wèn)題——負(fù)載均衡[2]。本文針對(duì)web系統(tǒng)的高并發(fā)業(yè)務(wù)處理方式之負(fù)載均衡進(jìn)行深入的研究,說(shuō)明實(shí)現(xiàn)負(fù)載均衡的三種方式。
1 ?負(fù)載均衡處理方式
1.1 ?HTTP重定向負(fù)載均衡
HTTP重定向是由HTTP請(qǐng)求代理和Web服務(wù)器共同實(shí)現(xiàn)的??蛻?hù)端瀏覽器(HTTP請(qǐng)求代理)發(fā)送HTTP請(qǐng)求,Web服務(wù)器接收到請(qǐng)求URL后發(fā)送302狀態(tài)碼響應(yīng),并通過(guò)HTTP請(qǐng)求響應(yīng)頭信息中的Location標(biāo)識(shí)返回一個(gè)新的URL發(fā)給客戶(hù)端瀏覽器,瀏覽器發(fā)現(xiàn)是302響應(yīng)碼,則再次發(fā)送一個(gè)新的URL給服務(wù)器,web服務(wù)器通過(guò)該URL尋找資源并將結(jié)果返回給用戶(hù)[3]。在該過(guò)程中,瀏覽器至少做了兩次請(qǐng)求。在Web應(yīng)該開(kāi)發(fā)中,我們經(jīng)常會(huì)使用它來(lái)實(shí)現(xiàn)請(qǐng)求的轉(zhuǎn)移以及頁(yè)面的跳轉(zhuǎn)。若將其應(yīng)用到負(fù)載均衡的過(guò)程中,則可以理解為瀏覽器的兩次請(qǐng)求,第一次是向作為調(diào)度者的服務(wù)器發(fā)起請(qǐng)求,以得到要真正接收處理的后端服務(wù)器的地址,第二次則是向該后端服務(wù)器發(fā)起請(qǐng)求,以得到后端服務(wù)器進(jìn)行處理后返回的結(jié)果[4]。
很明顯在這個(gè)過(guò)程中,我們關(guān)注于服務(wù)器,也就是調(diào)度者該采取何種策略合理分發(fā)請(qǐng)求。具體的策略一般包括隨機(jī)分配策略、輪詢(xún)策略、最小連接、hash等,具體如下:
(1)隨機(jī)分配策略:隨機(jī)分配請(qǐng)求到各個(gè)服務(wù)器,在請(qǐng)求量大的時(shí)候分配越均勻。
(2)輪詢(xún)策略(Round-Robin):該算法將用戶(hù)的請(qǐng)求順序分發(fā)給后端服務(wù)器,按順序從頭開(kāi)始,至尾結(jié)束,再重新開(kāi)始新一輪循環(huán)。該算法更適合于所有的服務(wù)器都有一樣的軟件和硬件配置,處理能力相同,只有在這種情況下,服務(wù)器間才能夠得相對(duì)負(fù)載均衡。
(3)最小連接(Least Connections):根據(jù)服務(wù)器當(dāng)前的處理情況,在多個(gè)請(qǐng)求到來(lái)時(shí),交付給處理連接數(shù)最少的服務(wù)器,它是動(dòng)態(tài)負(fù)載均衡算法。即使在每臺(tái)服務(wù)器處理能力各不相同,每筆業(yè)務(wù)處理量也不相同的情況下,也能夠在一定程度上降低服務(wù)器的負(fù)載[5]。
(4)Hash方式:相同的請(qǐng)求根據(jù)自定義的hash()算法總是到達(dá)同一個(gè)服務(wù)器,但是如果某個(gè)服務(wù)器發(fā)生宕機(jī),那么后面的請(qǐng)求都會(huì)重新計(jì)算,重新分配服務(wù)器,導(dǎo)致請(qǐng)求大量轉(zhuǎn)移。
1.2 ?DNS域名解析負(fù)載均衡
用戶(hù)向域名發(fā)送請(qǐng)求,DSN服務(wù)器按照開(kāi)發(fā)者自定義的調(diào)度策略返回一個(gè)IP地址給用戶(hù),用戶(hù)收到該IP地址后,重新向該IP地址發(fā)送請(qǐng)求,從而實(shí)現(xiàn)web服務(wù)器集群的負(fù)載均衡。
這種方式的負(fù)載均衡是交給DNS去做的,所以開(kāi)發(fā)者只需關(guān)注后端服務(wù)器的穩(wěn)定性和吞吐量即可。但由于DNS是無(wú)法知道各個(gè)服務(wù)器的實(shí)際負(fù)載狀況,它其實(shí)也是和HTTP重定向一樣,將接收到的一切請(qǐng)求均分給后端服務(wù)器,所以它也無(wú)法真正地實(shí)現(xiàn)負(fù)載均衡。
一般的大型網(wǎng)站會(huì)將域名解析作為一級(jí)負(fù)載均衡,在服務(wù)器內(nèi)部會(huì)進(jìn)行二級(jí)負(fù)載均衡,所以一般情況下,用戶(hù)獲得的IP地址實(shí)際上是內(nèi)部負(fù)載均衡服務(wù)器的IP地址[6]。
另外如果服務(wù)器發(fā)生故障,必須將它從調(diào)度策略中移除,將指向故障該服務(wù)器的DNS記錄暫停,由于修正DNS記錄在一定的時(shí)間后才會(huì)有效,即DNS更新延遲,有多種方式在意識(shí)到故障時(shí)來(lái)盡快修改DNS記錄,但是都需要人力,無(wú)法自動(dòng)實(shí)現(xiàn)故障轉(zhuǎn)移,所以當(dāng)我們監(jiān)測(cè)發(fā)現(xiàn)實(shí)際情況下某個(gè)的服務(wù)器出現(xiàn)問(wèn)題時(shí),可使用動(dòng)態(tài)DNS協(xié)議快速修改DNS記錄[7]。
1.3 ?反向代理負(fù)載均衡
反向代理器位于實(shí)際的web服務(wù)器前面,當(dāng)接收到用戶(hù)的請(qǐng)求時(shí),代理服務(wù)器作為調(diào)度者,按照設(shè)置好的負(fù)載均衡策略將請(qǐng)求轉(zhuǎn)發(fā)給真實(shí)的服務(wù)器,真實(shí)的服務(wù)器處理完該請(qǐng)求后將結(jié)果返回給代理服務(wù)器,用戶(hù)在這個(gè)過(guò)程中是不知道真實(shí)服務(wù)器的存在的。代理服務(wù)器的兩個(gè)IP地址,一個(gè)用于外部用戶(hù)訪問(wèn),一個(gè)用于內(nèi)部轉(zhuǎn)發(fā)。
相較于HTTP重定向,請(qǐng)求需要通過(guò)反向代理服務(wù)器下發(fā)到真實(shí)的服務(wù)器,瀏覽器通過(guò)反向代理服務(wù)器與后端真實(shí)的服務(wù)器進(jìn)行間接的交互,故而它可以保證反向代理服務(wù)器擁有絕對(duì)的控制權(quán)。
與DNS負(fù)載均衡相比,當(dāng)某個(gè)服務(wù)器發(fā)生故障時(shí),由于反向代理服務(wù)器的存在,如果系統(tǒng)檢測(cè)到服務(wù)器發(fā)生了故障,可以很快告訴反向代理服務(wù)器,將該故障服務(wù)器移除,那么請(qǐng)求就不會(huì)轉(zhuǎn)發(fā)到該故障服務(wù)器,從而將故障轉(zhuǎn)移,將請(qǐng)求分發(fā)給其他服務(wù)器來(lái)處理。
如果客戶(hù)端瀏覽器的請(qǐng)求數(shù)過(guò)多甚至大于了代理服務(wù)器的最高負(fù)載量,因?yàn)榉聪虼矸?wù)器處理所有的請(qǐng)求,那么會(huì)導(dǎo)致整個(gè)服務(wù)器集群的性能整體降低;當(dāng)后端服務(wù)器處理能力達(dá)到最大,通過(guò)增加后端服務(wù)器的數(shù)量解決別的請(qǐng)求是一種有效的方式,但不可以無(wú)限制增加,畢竟代理服務(wù)器有最大吞吐量的限制,故而反向代理服務(wù)器的擴(kuò)展是受到限制的。
2 ?結(jié)束語(yǔ)
本文討論了web系統(tǒng)高并發(fā)業(yè)務(wù)處理的方式——負(fù)載均衡[8-10],給出了相關(guān)的調(diào)度策略,詳細(xì)說(shuō)明了負(fù)載均衡的三種方式以及不同方式的優(yōu)缺點(diǎn),可根據(jù)情況合情合理地選擇合適的負(fù)載均衡方式,以提高系統(tǒng)對(duì)高并發(fā)業(yè)務(wù)處理的響應(yīng)速度,提高系統(tǒng)的整體性能。本文對(duì)大型web系統(tǒng)的性能[11]提高有一定的幫助作用。
參考文獻(xiàn)
[1] https://blog.csdn.net/github_37515779/article/details/79953788.
[2] 饒磊. 服務(wù)器集群負(fù)載均衡策略研究[J]. 計(jì)算機(jī)與現(xiàn)代化, 2013, 1.
[3] 陳恒. Spring MVC開(kāi)發(fā)技術(shù)指南[M]. 北京: 清華大學(xué)出版社, 2017.
[4] https://blog.csdn.net/shixiansen6535/article/details/81509480.
[5] https://www.cnblogs.com/data2value/p/6107450.html.
[6] 盧鵬. 幾種常見(jiàn)的網(wǎng)絡(luò)接入方式[J]. 軟件, 2017.
[7] 郭欣. 構(gòu)建高性能Web站點(diǎn)[M]. 北京: 電子工業(yè)出版社, 2012. 6.
[8] 馮學(xué)兵. Wireless HART 負(fù)載均衡方法研究[J]. 軟件, 2018, 39(2): 166-169.
[9] 龐玲. 網(wǎng)絡(luò)流量分析多機(jī)負(fù)載均衡系統(tǒng)設(shè)計(jì)[J]. 軟件, 2012, 33(5): 75-77.
[10] 王龍. 田野. 基于納什均衡的多用戶(hù)分布式系統(tǒng)負(fù)載均衡的研究[J]. 軟件, 2012, 33(12): 210-213.
[11] 王文明, 高經(jīng)緯. 一種Linux環(huán)境下搭建高性能網(wǎng)絡(luò)庫(kù)交互平臺(tái)的方法[J]. 軟件, 2012, 33(4): 50-54.