丁建峰
摘 要 高校選課系統(tǒng)在實(shí)際選課活動中屢屢癱瘓,需要采用何種方式來改善其整體性能?這里從架構(gòu)優(yōu)化的角度,提出了系統(tǒng)架構(gòu)優(yōu)化的路徑,給出了適用于不同訪問規(guī)模、改造成本、技術(shù)要求的架構(gòu)方案,并提出了系統(tǒng)架構(gòu)優(yōu)化實(shí)施的基本步驟。
關(guān)鍵詞 選課系統(tǒng) 架構(gòu)優(yōu)化 Nginx 負(fù)載均衡 LVS
中圖分類號:G473.4 文獻(xiàn)標(biāo)識碼:A DOI:10.16400/j.cnki.kjdkz.2018.08.008
Abstract The course selection system in colleges and universities is often paralyzed in the actual course selection activities. How to improve its overall performance? From the perspective of architecture optimization, this paper puts forward the way of system architecture optimization, gives the architecture scheme suitable for different access scale, transformation cost and technical requirements, and puts forward the basic steps of implementation of system architecture optimization.
Keywords course selection system; architecture optimization; Nginx; load balancing; LVS
0 引言
為了滿足學(xué)生大規(guī)模選課的需要,目前各高校普遍使用選課系統(tǒng)進(jìn)行網(wǎng)上選課。各校在選課的過程中普遍遇到了系統(tǒng)擁堵、服務(wù)癱瘓的問題。主要原因是為了公平起見各校通常指定某一時間開始選課,課程選課基于先選者先得,結(jié)果大量用戶同時搶跑,平時運(yùn)行穩(wěn)定的系統(tǒng)迅速崩潰。
為了解決高并發(fā)訪問下WEB應(yīng)用系統(tǒng)的性能問題,已有不少研究和實(shí)踐,主要有下述三類:一是如高宗振、[1]史強(qiáng)、[2]孔祥真 [3]等人對特定的負(fù)載均衡策略的研究;二是如謝佳運(yùn)、[4]鄧小善、[5]文捷等[6]從系統(tǒng)設(shè)計(jì)與開發(fā)角度對系統(tǒng)性能提升策略的討論;三是綜合上述兩個維度的研究與實(shí)踐,如潘旭武、[7]郝陽 [8]等人的研究。
這些研究比較側(cè)重于特定的技術(shù),如某一種負(fù)載均衡方案、某一種查詢優(yōu)化方法、某一種頁面性能提升技巧或是若干種技術(shù)的綜合運(yùn)用,但采用了這些技術(shù)或方法未必可以解決選課系統(tǒng)的困境。負(fù)載均衡本身并不能解決選課系統(tǒng)的問題,一些學(xué)校為解決問題花數(shù)十萬部署了負(fù)載均衡設(shè)備選課系統(tǒng)崩潰照舊。其他各種優(yōu)化方法技術(shù)也只是在一定程度、某些環(huán)節(jié)上提升了系統(tǒng)的性能,在大規(guī)模并發(fā)訪問情形下這些效果非常有限。要從根本上解決選課系統(tǒng)性能瓶頸問題,需從系統(tǒng)架構(gòu)上進(jìn)行改進(jìn),一個性能可伸縮的彈性架構(gòu)才能真正應(yīng)對大規(guī)模并發(fā)訪問帶來的挑戰(zhàn)。本文將從系統(tǒng)架構(gòu)的角度討論選課系統(tǒng)性能優(yōu)化的路徑,并討論了高校實(shí)施架構(gòu)優(yōu)化的具體步驟。
1 系統(tǒng)架構(gòu)優(yōu)化路徑
有句話說“架構(gòu)是進(jìn)化而來的”,意指架構(gòu)優(yōu)化是針對現(xiàn)有狀況不斷改進(jìn)的過程,是對現(xiàn)有的薄弱環(huán)節(jié)進(jìn)行改進(jìn)的過程。因此本文將從選課系統(tǒng)的初始狀態(tài)開始根據(jù)訪問量的增加逐步改進(jìn)系統(tǒng)架構(gòu)。
1.1 基于DNS對WEB站點(diǎn)層進(jìn)行擴(kuò)展
選課系統(tǒng)典型的初始架構(gòu)為“瀏覽器——單WEB服務(wù)器——單數(shù)據(jù)庫服務(wù)器”模式,隨著用戶并發(fā)訪問量的增加,通常WEB服務(wù)器首先出現(xiàn)服務(wù)瓶頸,因此首先要著手對WEB站點(diǎn)層進(jìn)行水平擴(kuò)展。
圖1是在初始架構(gòu)基礎(chǔ)上通過DNS對WEB站點(diǎn)進(jìn)行水平擴(kuò)展的示意圖,這是一種低成本且十分有效的擴(kuò)展模式,理論上WEB服務(wù)器數(shù)可以無限擴(kuò)展。具體只需要將各WEB站點(diǎn)IP解析在同一個域名下,用戶訪問該域名時,DNS輪動返回各個IP。如此實(shí)現(xiàn)了對WEB服務(wù)器的負(fù)載均衡。這種方式可以迅速擴(kuò)展WEB站點(diǎn)規(guī)模,但有下列弊端:
(1)DNS不會感知到具體WEB站點(diǎn)的可用性,當(dāng)某個WEB站點(diǎn)服務(wù)故障(如網(wǎng)絡(luò)中斷、系統(tǒng)崩潰等),用戶對這個站點(diǎn)的訪問將失敗。
(2)擴(kuò)容非實(shí)時。DNS域名解析的生效需要一個刷新周期。特別是在公網(wǎng)運(yùn)營商DNS緩存的刷新時間更長,可能會達(dá)數(shù)小時,會一定程度影響系統(tǒng)使用。
(3)暴露了各個WEB服務(wù)器的地址。因?yàn)槭腔贒NS解析的,所以每個WEB服務(wù)器的IP都需公開。這帶來了潛在的風(fēng)險(xiǎn)。
1.2 基于Nginx對WEB站點(diǎn)層進(jìn)行擴(kuò)展
為了避免圖1 DNS負(fù)載均衡模式的問題,可以改用反向代理Nginx對WEB站點(diǎn)層進(jìn)行水平擴(kuò)展,見圖2。Nginx是一個高性能的 HTTP 和反向代理服務(wù)器,也是目前使用最為廣泛的HTTP軟負(fù)載均衡器。它可以承擔(dān)相當(dāng)高的負(fù)載壓力,一般能支撐超過每秒數(shù)萬次的訪問請求(與服務(wù)器的配置及服務(wù)的優(yōu)化程度有關(guān)),甚至有服務(wù)器經(jīng)優(yōu)化后達(dá)到了支持每秒數(shù)十萬的訪問請求的水平。Nginx支持對故障WEB站點(diǎn)的探測感知,能夠把流量引導(dǎo)到非故障的WEB站點(diǎn),同時也沒有DNS負(fù)載均衡模式下暴露過多IP、擴(kuò)容非實(shí)時等問題。但這種模式也有缺點(diǎn):(1)多了一個反向代理層,架構(gòu)變復(fù)雜,多了一道反向代理層的延時。(2)反向代理層的Nginx為單點(diǎn)部署,如發(fā)生故障系統(tǒng)將不可訪問。這對于選課這樣的大規(guī)模正式活動來說是一個風(fēng)險(xiǎn)。
1.3 通過Nginx集群解決反向代理層高可用問題
為避免圖2中反向代理層的單點(diǎn)故障風(fēng)險(xiǎn),圖3用兩臺Nginx組成一個集群,分別部署Keepalived,設(shè)置成相同的虛IP,實(shí)現(xiàn)Nginx負(fù)載均衡服務(wù)的高可用。當(dāng)一臺Nginx掛了,Keepalived能夠探測到并將流量自動遷移到另一臺Nginx上。Keepalived是一個運(yùn)行于Linux下的開源軟件,主要提供負(fù)載均衡和高可用功能。圖3方案解決了反向代理層的高可用問題,但是Nginx集群的資源利用率下降到50%(一主一備)。對于萬人以下的院校來說,選課活動每秒的HTTP請求峰值一般在10萬以下,該架構(gòu)的WEB站點(diǎn)響應(yīng)能力應(yīng)能滿足要求,最多再適當(dāng)提高Nginx服務(wù)器的配置應(yīng)能解決問題。但對于更大規(guī)模的并發(fā)訪問,超過了Nginx服務(wù)器單機(jī)系統(tǒng)的處理能力,該如何解決?
1.4 反向代理層性能瓶頸的解決
要解決圖3中反向代理層Nginx集群的性能瓶頸,可以基于DNS對反向代理層進(jìn)行水平擴(kuò)展(圖4),原理與圖1中DNS對WEB站點(diǎn)層擴(kuò)展相同。這個方案下,反向代理層的Nginx集群可以無限擴(kuò)展,實(shí)現(xiàn)了高性能與高可用;WEB站點(diǎn)層同樣可以不斷擴(kuò)展,實(shí)現(xiàn)了高性能和高可用。
圖4方案中Nginx集群也可以使用其他負(fù)載均衡集群代替,如LVS(Linux Virtual Server)或F5集群。替換后,負(fù)載均衡層多個LVS或F5集群也通過DNS實(shí)現(xiàn)彈性擴(kuò)展。相較Nginx,LVS或F5有著更強(qiáng)的處理性能,但部署成本上升。
1.5數(shù)據(jù)層架構(gòu)的優(yōu)化與擴(kuò)展
系統(tǒng)架構(gòu)改到圖4的程度,至少到WEB站點(diǎn)層為止高性能、高可用都得到了保證,但此時數(shù)據(jù)庫很可能成為瓶頸了。數(shù)據(jù)層同樣需要進(jìn)行改進(jìn),數(shù)據(jù)層庫架構(gòu)優(yōu)化的目的同樣是實(shí)現(xiàn)高性能、高可用。
常見的是對數(shù)據(jù)庫實(shí)施主從分離、讀寫分離。從庫從主庫進(jìn)行復(fù)制用于讀取,主庫用于寫操作。通過設(shè)立多個從庫可保證讀的高可用,但沒有解決寫的高可用(以及高性能),另外主庫寫入數(shù)據(jù)、從庫讀取數(shù)據(jù)的時間差會造成兩者數(shù)據(jù)不一致。主、從庫越多數(shù)據(jù)一致性的問題就越多,這些都要額外的算法控制。
數(shù)據(jù)庫 “master--shadow master”雙主架構(gòu)可以解決主從庫數(shù)據(jù)不一致的問題。主庫master提供讀寫服務(wù),另一個是影子主庫shadow-master平時只與master進(jìn)行數(shù)據(jù)同步并作為后備,master掛了后shadow-master迅速頂上變?yōu)閙aster。這個模式同時解決讀寫的高可用,并且消除了數(shù)據(jù)的不一致性問題。但雙主模式,沒有解決高性能,如何提高性能呢?
首先增加緩存,見圖5。讀數(shù)據(jù)時首先從緩存讀取,緩存沒有再到主庫讀(然后數(shù)據(jù)也復(fù)制到cache一份)。但是主庫也是寫的目標(biāo)庫,因此主庫與緩存之間也會出現(xiàn)數(shù)據(jù)不一致問題。解決辦法是寫之前淘汰緩存數(shù)據(jù)。圖5中還增加了服務(wù)層,這是因?yàn)榫彺嬉?、?shù)據(jù)一致性處理等使得對數(shù)據(jù)庫的操作更加復(fù)雜,為了屏蔽這些細(xì)節(jié),讓上層專注于業(yè)務(wù),因此系統(tǒng)架構(gòu)中應(yīng)增設(shè)服務(wù)層負(fù)責(zé)具體的數(shù)據(jù)庫訪問,并對上層(WEB站點(diǎn)層)提供透明數(shù)據(jù)服務(wù)。
其次是對數(shù)據(jù)庫進(jìn)行水平擴(kuò)展,也就是進(jìn)行水平切分。水平切分就是把原來一個庫中的數(shù)據(jù)切分一部分到其他的庫中去,但各庫之間結(jié)構(gòu)是相同的。選課系統(tǒng)中這種方式尤其適用,如學(xué)生表,完全可以把已畢業(yè)的學(xué)生數(shù)據(jù)分到另一個庫中,也可以根據(jù)入學(xué)年份進(jìn)行切分,從而提高數(shù)據(jù)庫訪問性能。圖5進(jìn)行數(shù)據(jù)庫切分后,變?yōu)?個庫,見圖6;還可以切分為更多的庫。這樣數(shù)據(jù)層的水平擴(kuò)展得以實(shí)現(xiàn),根本上解決了數(shù)據(jù)層的性能瓶頸。
1.6 服務(wù)層的擴(kuò)展
數(shù)據(jù)層變得復(fù)雜后,需要引入服務(wù)層,如圖6所示。但是在大規(guī)模并發(fā)訪問下,服務(wù)層節(jié)點(diǎn)也可能成為一個性能瓶頸。服務(wù)層的水平擴(kuò)展是通過WEB站點(diǎn)層中“服務(wù)連接池”來進(jìn)行的,增加一個服務(wù)層節(jié)點(diǎn)只需要再WEB站點(diǎn)的“服務(wù)連接池”中增加一個連接。理論上服務(wù)節(jié)點(diǎn)也是可以無限擴(kuò)展的。服務(wù)層的增加與擴(kuò)展需要開發(fā)商的支持。
到此,系統(tǒng)在負(fù)載均衡層、WEB站點(diǎn)層、服務(wù)層、數(shù)據(jù)層都實(shí)現(xiàn)了彈性擴(kuò)展,都能提供高性能、高可用的服務(wù),大規(guī)模并發(fā)選課問題得到了根本性的解決。
2 系統(tǒng)架構(gòu)優(yōu)化的實(shí)施
2.1 架構(gòu)優(yōu)化的前期準(zhǔn)備
系統(tǒng)架構(gòu)的優(yōu)化與擴(kuò)展,有些是需要開發(fā)商支持的,如數(shù)據(jù)庫架構(gòu)的改造、緩存的設(shè)計(jì)與使用、服務(wù)層的引入等,有的可能甚至需要開發(fā)商進(jìn)行比較大的改動;有些是高校方面比較容易實(shí)施的,如負(fù)載均衡層、WEB站點(diǎn)層的水平擴(kuò)展等。各校應(yīng)該根據(jù)開發(fā)商的支持力度、系統(tǒng)改造的預(yù)算情況、自身的技術(shù)能力、現(xiàn)有的設(shè)備設(shè)施以及網(wǎng)上選課工作的具體任務(wù)情況研究架構(gòu)優(yōu)化的具體實(shí)施方案。
2.2 系統(tǒng)架構(gòu)優(yōu)化的步驟
系統(tǒng)的性能優(yōu)化需要理清思路,按步驟實(shí)施。
(1)根據(jù)實(shí)際條件確定優(yōu)化的目標(biāo)架構(gòu)。比如開發(fā)商目前不會也沒有時間對系統(tǒng)層次、數(shù)據(jù)庫架構(gòu)進(jìn)行改動,那么圖4可以作為一個系統(tǒng)架構(gòu)優(yōu)化的基本模型;如果選課人數(shù)也不是很多,那么可以選圖3或圖2;如果對Ngnix也不熟悉或來不及部署,那么也姑且可以用圖1來應(yīng)對。
(2)按選定的目標(biāo)架構(gòu)基本模型的未擴(kuò)展?fàn)顟B(tài)調(diào)整原有系統(tǒng)。對調(diào)整后系統(tǒng)在未擴(kuò)展?fàn)顟B(tài)下進(jìn)行壓力測試,確定其系統(tǒng)性能,能支持多少并發(fā)連接以及多快的響應(yīng)能力。
(3)對相關(guān)層次進(jìn)行一個節(jié)點(diǎn)的擴(kuò)展,進(jìn)行壓力測試,記錄其性能的增量。壓力測試工具可以用Loadrunner、Jmeter、Tsung等。
(4)根據(jù)選課任務(wù)參與選課的學(xué)生數(shù)量估算峰值的并發(fā)連接、請求數(shù)量,估算相關(guān)層次節(jié)點(diǎn)的水平擴(kuò)展數(shù)量并實(shí)施擴(kuò)展。
(5)對擴(kuò)展后的系統(tǒng)按峰值壓力進(jìn)行壓力測試,如果沒問題則投入實(shí)際使用,否則要找出問題進(jìn)行調(diào)整,通過測試后再投入使用。
3 結(jié)語
本文從選課系統(tǒng)的初始架構(gòu)開始,在并發(fā)訪問規(guī)模不斷加大、投入改造的預(yù)算逐步增加的假設(shè)下推出了選課系統(tǒng)架構(gòu)優(yōu)化的路徑,并給出了系統(tǒng)架構(gòu)優(yōu)化的實(shí)施步驟。具體的方案需要各校結(jié)合實(shí)際情況來采用,同時需要注意各方案的局限點(diǎn),比如“基于DNS對WEB站點(diǎn)層的擴(kuò)展”需要保證各站點(diǎn)自身不出問題,如“基于Nginx(單機(jī))對WEB站點(diǎn)層擴(kuò)展”需要Nginx服務(wù)可靠同時注意其本身的性能上限。當(dāng)然系統(tǒng)架構(gòu)的優(yōu)化還有其它很多方法,本文所給的方案僅供參考。
參考文獻(xiàn)
[1] 高宗振.基于負(fù)載均衡的在線選課系統(tǒng)的研究與實(shí)現(xiàn)[D].青島:中國海洋大學(xué),2012.
[2] 史強(qiáng),管紅杰.基于云動態(tài)資源擴(kuò)展的選課系統(tǒng)優(yōu)化實(shí)踐[J].軟件導(dǎo)刊,2016.15(6):77-79.
[3] 孔祥真,張丁,李忠遠(yuǎn).Linux負(fù)載均衡集群技術(shù)在網(wǎng)絡(luò)服務(wù)器中的應(yīng)用[J].軟件導(dǎo)刊,2016.15(12):144-147.
[4] 謝佳運(yùn). ASP.NET網(wǎng)站的系統(tǒng)架構(gòu)和性能優(yōu)化[J].電腦知識與技術(shù),2008.3(6):1166-1167.
[5] 鄧小善,龍艷軍.高訪問量網(wǎng)站性能監(jiān)測與優(yōu)化的設(shè)計(jì)與實(shí)現(xiàn)[J].現(xiàn)代計(jì)算機(jī),2009(301):149-151.
[6] 文捷,吳慶杰,陳翼,等.復(fù)旦大學(xué)選課系統(tǒng)的性能優(yōu)化策略研究和實(shí)踐[J].中山大學(xué)學(xué)報(bào)(自然科學(xué)版),2009.48:95-99.
[7] 潘旭武,陳啟華,張建勇.高校選課系統(tǒng)性能優(yōu)化研究[J].中國教育信息化,2013(5):76-78.
[8] 郝陽.高校教務(wù)管理網(wǎng)上選課系統(tǒng)優(yōu)化研究[D].青島:山東科技大學(xué),2011.