林平榮,施曉權(quán),楊俊欽,楊少冬,林哲源

(廣州大學(xué) 華軟軟件學(xué)院 軟件研究所,廣州 510990)

軟件開發(fā)技術(shù)的不斷發(fā)展以及業(yè)務(wù)需求的不斷變更,使越來越多的軟件系統(tǒng)成為遺留系統(tǒng).遺留系統(tǒng)指對(duì)新技術(shù)或業(yè)務(wù)需求不再適應(yīng),但由于替換和修改成本過高而仍在被使用的計(jì)算機(jī)系統(tǒng)或應(yīng)用程序[1].遺留系統(tǒng)大部分為早期開發(fā)并投入使用[2],具有如下特征:(1)業(yè)務(wù)邏輯復(fù)雜,維護(hù)難;(2)架構(gòu)陳舊且高度耦合,牽一發(fā)而動(dòng)全身,效率低;(3)開發(fā)人員流動(dòng)性大;(4)系統(tǒng)文檔缺失;(5)業(yè)務(wù)邏輯與代碼邏輯較為混亂.對(duì)于企業(yè)或其他組織而言,處理遺留系統(tǒng)面臨選擇,要么拋棄遺留系統(tǒng)開發(fā)更適應(yīng)新軟硬件技術(shù)和新業(yè)務(wù)需求的系統(tǒng),要么保留繼續(xù)運(yùn)行使用.鑒于新系統(tǒng)開發(fā)的人力物力成本較高,且有一定風(fēng)險(xiǎn),同時(shí)遺留系統(tǒng)包含大量數(shù)據(jù)和業(yè)務(wù)邏輯信息,是企業(yè)相當(dāng)重要的企業(yè)資源[3],完全拋棄會(huì)造成資源的丟失,所以盡管遺留系統(tǒng)存在諸多問題,仍處于運(yùn)行狀態(tài)[4].

隨著時(shí)間的推移,仍在運(yùn)行的遺留系統(tǒng)的用戶數(shù)以及數(shù)據(jù)量不斷增加,暴露出來的問題越來越多,尤其是性能和安全問題.經(jīng)過文獻(xiàn)檢索,發(fā)現(xiàn)有大量的關(guān)于Web 應(yīng)用系統(tǒng)性能和安全方面的優(yōu)化方案被提出.這些方法雖然在某種程度上有一定的優(yōu)化效果,但大部分并不是在遺留系統(tǒng)背景下所提出,許多方法并不完全適用,即使是針對(duì)遺留系統(tǒng)在工程方面的文獻(xiàn)[4–7]也較少涉及安全方面的優(yōu)化.基于此,本文將在大型遺留系統(tǒng)特定背景下,多角度挖掘遺留系統(tǒng)性能和安全方面的痛點(diǎn),綜合考慮各方面優(yōu)化技術(shù),但不贅述窮舉大部分文獻(xiàn)提及的通用方法,最后給出具體優(yōu)化方案.

1 性能優(yōu)化

1.1 前端

遺留系統(tǒng)當(dāng)時(shí)的開發(fā)時(shí)期并沒有像現(xiàn)在各種開發(fā)技術(shù)的多樣與規(guī)范.前端開發(fā)技術(shù)主要以表格布局進(jìn)行排版,以切片進(jìn)行內(nèi)容展示,以微軟操作系統(tǒng)自帶的IE 瀏覽器作為瀏覽網(wǎng)頁的載體.隨著人們的需求與技術(shù)的發(fā)展,優(yōu)雅的界面、響應(yīng)的速度、數(shù)據(jù)的安全愈加獲得人們的重視.

(1)隨著各個(gè)新的基于不同引擎的瀏覽器的加入,遺留系統(tǒng)的Web 前端出現(xiàn)了瀏覽器兼容性問題,訪問頁面有排版錯(cuò)亂、按鈕點(diǎn)擊無反應(yīng)等現(xiàn)象.究其原因主要在各個(gè)廠商的瀏覽器內(nèi)核對(duì)同一段代碼解析不一,導(dǎo)致頁面呈現(xiàn)效果不統(tǒng)一,操作效果無法被解析.為了解決系統(tǒng)在各個(gè)瀏覽器的兼容問題,可以選擇優(yōu)雅降級(jí)和漸進(jìn)增強(qiáng).嘗試從低版本瀏覽器到高版本瀏覽器的逐步優(yōu)化的過程,結(jié)合漸進(jìn)增強(qiáng)的優(yōu)化方式,即能保證遺留系統(tǒng)存在的功能不被破壞又能在新一代的主流瀏覽器中進(jìn)行操作.

(2)遺留系統(tǒng)的頁面布局皆為表格布局,而現(xiàn)在編寫代碼更多的是講究規(guī)范化和語義化,且在非表格化數(shù)據(jù)顯示的模塊下并不提倡用表格標(biāo)簽做其他處理,在使用table 標(biāo)簽布局會(huì)使網(wǎng)頁瀏覽的速度變慢,這與table 標(biāo)簽的渲染有關(guān)[8].可以用div 加載方式進(jìn)行渲染,即讀即加載,同時(shí)引入異步加載局部更新技術(shù).局部更新只針對(duì)需要重新加載的局部信息,可以有效提升響應(yīng)速度,提高用戶體驗(yàn),服務(wù)器壓力也會(huì)減少.

(3)遺留系統(tǒng)中的CSS 文件和JavaScript 文件代碼編寫大多以覆蓋為主.無論是HTML 文件還是CSS文件,代碼里都存在著一些被廢棄的標(biāo)簽和樣式寫法,文件編寫沒有進(jìn)行一個(gè)整理和歸類,導(dǎo)致代碼冗余.采用現(xiàn)代前端開發(fā)技術(shù)的工程化能對(duì)遺留系統(tǒng)的腳本進(jìn)行優(yōu)化,有利于代碼的更好維護(hù)與管理.前端工程化是以宏觀的角度、更遠(yuǎn)的思維看待和開發(fā)項(xiàng)目的一種思想,而模塊化和組件化則是工程化的表現(xiàn)形式,如圖1所示.模塊化是將一個(gè)功能當(dāng)做一個(gè)模塊進(jìn)行開發(fā),實(shí)現(xiàn)高效復(fù)用和分開管理,不僅JavaScript 代碼能實(shí)現(xiàn)模塊化,CSS 樣式也可以實(shí)現(xiàn)模塊化.常見的JavaScript模塊化方案有AMD、CommonJS、ES6 Module 等,而CSS 模塊化則有l(wèi)ess、sass、stylus 等預(yù)處理器進(jìn)行實(shí)現(xiàn).組件化則是將頁面上的可視區(qū)域和交互區(qū)域分成各個(gè)組件,每個(gè)組件都是獨(dú)立的,每個(gè)組件包含模板、樣式和邏輯.不同的頁面根據(jù)內(nèi)容不同,對(duì)各個(gè)組件進(jìn)行自由組合.模塊化和組件化能對(duì)代碼實(shí)現(xiàn)高效復(fù)用和降耦管理,這也是現(xiàn)代前端開發(fā)技術(shù)倡導(dǎo)前端工程化的原因之一.

圖1 模塊化和組件化示意圖

1.2 數(shù)據(jù)庫

數(shù)據(jù)庫優(yōu)化的主要目的就是最大限度地降低數(shù)據(jù)響應(yīng)時(shí)間和提高數(shù)據(jù)庫的吞吐量[9].一個(gè)應(yīng)用程序的數(shù)據(jù)庫性能,通常是指數(shù)據(jù)的增、刪、改、查耗時(shí)性能,而耗時(shí)主要是SQL 語句從執(zhí)行開始到完成所消耗的時(shí)間,這個(gè)過程主要指標(biāo)有:數(shù)據(jù)和索引等讀寫的I/O消耗時(shí)間、CPU 消耗時(shí)間、總的執(zhí)行消耗時(shí)間.以微軟的SQL Server 數(shù)據(jù)庫為例,可以通過3 種工具(SQL Server Profiler、查詢窗口、SQL 活動(dòng)監(jiān)視器)進(jìn)行相應(yīng)的性能查詢分析.

一般情況下可以通過優(yōu)化SQL 語句、創(chuàng)建索引等手段來進(jìn)行數(shù)據(jù)庫優(yōu)化,然而在排除硬件資源充足、SQL 語句和索引創(chuàng)建合理的情況下,有可能發(fā)現(xiàn)性能提升仍然不夠理想,分析深層次原因是數(shù)據(jù)庫碎片積累過多且沒有定期進(jìn)行整理.

遺留系統(tǒng)運(yùn)行年限較長(zhǎng),信息數(shù)據(jù)、索引數(shù)據(jù)等都在不斷增加,相應(yīng)存儲(chǔ)頁數(shù)量也不斷增長(zhǎng),數(shù)據(jù)頁上也容易形成碎片(即部分?jǐn)?shù)據(jù)的大小超出了當(dāng)前頁的剩余空間,導(dǎo)致無法在當(dāng)前繼續(xù)增加數(shù)據(jù),只能新開一個(gè)頁).在運(yùn)維的過程中只注重索引創(chuàng)建卻忽視了索引碎片的維護(hù),從而導(dǎo)致性能的直線下降.可以修復(fù)表的數(shù)據(jù)及索引碎片,把相關(guān)數(shù)據(jù)文件重新整理,但也不能過于頻繁,可根據(jù)表的讀寫頻率按月、季、年來進(jìn)行修復(fù).

碎片整理前,如果監(jiān)測(cè)到某條SQL 語句執(zhí)行過慢,通過查詢其中某個(gè)表索引碎片,如圖2所示,發(fā)現(xiàn)其中邏輯掃描碎片和區(qū)掃描碎片都超過70%,掃描密度只有18%,并且平均頁密度也只有58.94%,這意味著“ROOM”表的數(shù)據(jù)頁存在很多碎片,其性能會(huì)損耗一部分在碎片當(dāng)中.這個(gè)時(shí)候單獨(dú)查詢表“ROOM”,其邏輯讀取(已經(jīng)查詢過并且沒有數(shù)據(jù)變更,數(shù)據(jù)已被放到內(nèi)存中)就達(dá)到72 次.

圖2 整理前邏輯掃描碎片

在掃描碎片整理后,發(fā)現(xiàn)掃描密度變?yōu)?5.71%,掃描邏輯碎片降低為2.17%,平均頁密度提升到99.25%,并且其邏輯讀取次數(shù)降低為48 次,如圖3所示.也就是在碎片較低的時(shí)候,其邏輯讀取次數(shù)相應(yīng)的降低,性能損耗降低了,查詢性能就提高了.

圖3 整理后邏輯掃描碎片

1.3 服務(wù)器

早期開發(fā)的遺留系統(tǒng)基本以單體形態(tài)部署在服務(wù)器上.隨著用戶量及數(shù)據(jù)量的增加,系統(tǒng)性能瓶頸逐漸暴露,用戶體驗(yàn)越來越差.常規(guī)做法就是加大硬件投入,使用性能更好的服務(wù)器,但受限于系統(tǒng)采用的陳舊技術(shù),硬件資源使用率不是很高,并不能很好地發(fā)揮服務(wù)器全部性能.比如一些使用JDK1.4 開發(fā)的Web 系統(tǒng),它并不支持使用泛型,所有的數(shù)據(jù)對(duì)象只能使用Object接收,在對(duì)象轉(zhuǎn)換之間花費(fèi)了大量的不必要計(jì)算,而在多線程只能使用傳統(tǒng)的線程池方式實(shí)現(xiàn).使用JDK1.5以上開發(fā)的Web 系統(tǒng)在數(shù)據(jù)對(duì)象轉(zhuǎn)換的開銷要比前者少得多,性能也就優(yōu)于前者,但因此升級(jí)JDK 版本會(huì)導(dǎo)致許多代碼需要重寫,代價(jià)太大.

為了應(yīng)對(duì)傳統(tǒng)的單體應(yīng)用模式無法承擔(dān)大量并發(fā)業(yè)務(wù)請(qǐng)求的問題,服務(wù)器集群技術(shù)應(yīng)運(yùn)而生.為了能在服務(wù)器集群中合理分配業(yè)務(wù),使各個(gè)服務(wù)器都發(fā)揮應(yīng)有的性能,負(fù)載均衡機(jī)制及均衡算法成為了關(guān)鍵[10].Nginx 作為中間服務(wù)器,可以友好的切入到大型遺留系統(tǒng),實(shí)現(xiàn)動(dòng)態(tài)拓展而不須改變系統(tǒng)本身,從而改進(jìn)系統(tǒng)的性能,增加用戶體驗(yàn).遺留系統(tǒng)可以采用Nginx 負(fù)載均衡技術(shù),使用ip_hash 算法,將特定用戶的請(qǐng)求分發(fā)給特定的服務(wù)器,通過動(dòng)態(tài)拓展服務(wù)器,增加系統(tǒng)的承載能力,動(dòng)態(tài)拓展示意圖如圖4所示.

圖4 Nginx 動(dòng)態(tài)拓展示意圖

使用此方法可以在很大程度上緩解并發(fā)壓力,但是對(duì)數(shù)據(jù)庫服務(wù)器的性能也有了更高要求,因此對(duì)數(shù)據(jù)庫也要進(jìn)行優(yōu)化,同樣是采用數(shù)據(jù)庫動(dòng)態(tài)拓展技術(shù),根據(jù)使用的數(shù)據(jù)庫不同可以選擇不同的集群捆綁中間件,比較常用的有阿里B2B 團(tuán)隊(duì)的Cobar、360 團(tuán)隊(duì)的Atlas 等等.

1.4 架構(gòu)重構(gòu)與演進(jìn)

遺留系統(tǒng)陳舊的技術(shù)架構(gòu)很難支撐日益復(fù)雜的業(yè)務(wù)線,無法滿足系統(tǒng)新的性能要求,另外如JDK、Weblogic 等未及時(shí)升級(jí)換代,導(dǎo)致技術(shù)革新寸步難行,只能在原架構(gòu)基礎(chǔ)上繼續(xù)堆砌新業(yè)務(wù),逐漸演化成一個(gè)大型遺留系統(tǒng).為了提升性能及日后嵌入更多的新需求,選擇合適的技術(shù)架構(gòu)進(jìn)行重構(gòu),保證架構(gòu)平滑演進(jìn)是必須考慮的.此外,還有一種方法就是對(duì)架構(gòu)進(jìn)行重寫,但很難確保系統(tǒng)的所有業(yè)務(wù)邏輯都被正確認(rèn)識(shí)和實(shí)現(xiàn),而且成本和風(fēng)險(xiǎn)很高.為了穩(wěn)定現(xiàn)有業(yè)務(wù)的正常開展,選擇在維護(hù)現(xiàn)有系統(tǒng)的基礎(chǔ)上,同時(shí)進(jìn)行新技術(shù)的重構(gòu)工作是比較好的方式,這樣既保障了業(yè)務(wù)的迭代需求,又能進(jìn)行新架構(gòu)的重構(gòu).

針對(duì)目前大型遺留系統(tǒng),架構(gòu)升級(jí)不能一蹴而就,要依據(jù)不同功能以及業(yè)務(wù)邏輯,完成系統(tǒng)級(jí)別的拆分,同時(shí)對(duì)于第三方服務(wù)進(jìn)行解耦,拆分出來獨(dú)立部署,并且實(shí)現(xiàn)數(shù)據(jù)庫的主從分離.獨(dú)立擁有拆分的DB,避免業(yè)務(wù)引發(fā)連鎖故障問題,系統(tǒng)間通過Hessian 實(shí)現(xiàn)RPC通信.

第1 步.將遺留系統(tǒng)拆分出多個(gè)業(yè)務(wù)邏輯相對(duì)獨(dú)立的子系統(tǒng),DB 暫不拆分,多套系統(tǒng)繼續(xù)共用一個(gè)DB,只是根據(jù)業(yè)務(wù)邏輯劃分依賴的表,不同業(yè)務(wù)邏輯系統(tǒng)不能相互訪問,只能訪問歸屬自己的表,進(jìn)而保證原系統(tǒng)業(yè)務(wù)不受影響,同時(shí)也保障新拆分的業(yè)務(wù)系統(tǒng)工作得以繼續(xù)進(jìn)行.第2 步.通過系統(tǒng)層面的拆分后,接下來就是DB 層面的拆分,將各個(gè)系統(tǒng)依賴的表獨(dú)立拆分,分別放到不同的RDS 數(shù)據(jù)庫,做到物理層隔離.這兩個(gè)步驟充分將大型遺留系統(tǒng)解耦,獨(dú)立拆出服務(wù)化組件,供其他服務(wù)調(diào)用.

有了合理的服務(wù)化拆分,可輕易演化為微服務(wù)架構(gòu).微服務(wù)可以將單體應(yīng)用細(xì)化為可相互協(xié)作、配合的一組小服務(wù),使得服務(wù)間開發(fā)自由、獨(dú)立部署、易于維護(hù)[11].微服務(wù)架構(gòu)形式在滿足系統(tǒng)功能之外,對(duì)系統(tǒng)的非功能特性也有顯著提升[12].將那些容易引起性能問題的業(yè)務(wù)拆分獨(dú)立微服務(wù)組件,微服務(wù)都圍著具體業(yè)務(wù)進(jìn)行構(gòu)建,由專人研發(fā)和維護(hù),結(jié)合架構(gòu)拆分,實(shí)施微服務(wù)架構(gòu).實(shí)施過程中,會(huì)產(chǎn)生很多微服務(wù)以及子系統(tǒng),各個(gè)系統(tǒng)的配置信息都以明文形式在配置文件中,固定化了各種定時(shí)任務(wù)的執(zhí)行規(guī)則,難以集中管理,可以選擇Disconf 和Elastic-Job 分別作為分布式配置管理、任務(wù)調(diào)度.

通過以上步驟實(shí)施,系統(tǒng)與微服務(wù)組件已非常容易擴(kuò)展.以服務(wù)為中心,全面構(gòu)建微服務(wù)組件,大型遺留系統(tǒng)可以具備高可用、高性能等特性.隨著服務(wù)越來越多越復(fù)雜,服務(wù)鏈路調(diào)用必須加以跟蹤,以便快速發(fā)現(xiàn)調(diào)用過程中需要優(yōu)化的地方,可以引入美團(tuán)點(diǎn)評(píng)的APM 工具Cat 實(shí)現(xiàn)實(shí)時(shí)監(jiān)控,與Dubbo 快速整合,通過全局鏈路ID 實(shí)現(xiàn)鏈路跟蹤功能.雖然對(duì)大型遺留系統(tǒng)進(jìn)行拆分,但還未做到快速彈性擴(kuò)展.接下來,拆好的微服務(wù)與Docker 容器結(jié)合,抵御業(yè)務(wù)高峰期沖擊,快速自動(dòng)擴(kuò)展服務(wù)器,低峰時(shí)期,可以自動(dòng)回收服務(wù)器.整個(gè)微服務(wù)架構(gòu)如圖5所示.

圖5 微服務(wù)架構(gòu)圖

2 安全優(yōu)化

2017年6月1 號(hào)《中華人民共和國(guó)網(wǎng)絡(luò)安全法》正式頒布實(shí)施,各大企業(yè)、高校對(duì)各自現(xiàn)有運(yùn)作的系統(tǒng)安全問題更加重視.遺留系統(tǒng)使用的技術(shù)過于陳舊導(dǎo)致一些安全問題修復(fù)難度增加.

以基于JDK1.4 開發(fā)的遺留系統(tǒng)為例,系統(tǒng)采用Cookie 技術(shù)來維持會(huì)話,通過使用js 進(jìn)行XSS 腳本攻擊,可以輕易地獲取Cookie 信息.如果Cookie 中設(shè)置了HttpOnly 屬性,那么通過js 腳本將無法讀取到Cookie 信息,這樣能有效地防止XSS 攻擊,增加Cookie的安全性.但是由于JDK1.4 無法設(shè)置HttpOnly 這一屬性,因此在原系統(tǒng)層面無法解決該問題,只能引入中間件攔截用戶請(qǐng)求,進(jìn)行相關(guān)處理后再請(qǐng)求系統(tǒng),即給系統(tǒng)加多一層防火墻來保護(hù)系統(tǒng)的安全.采用Nginx來進(jìn)行攻擊防護(hù),通過在Nginx 的proxy 模式將客戶端的請(qǐng)求攔截,利用HttpOnly 防止XSS 攻擊獲取Cookie 信息,SameSite 防止 CSRF 攻擊和用戶追蹤,再結(jié)合ngx_lua_waf 實(shí)現(xiàn)安全web 應(yīng)用防火墻.通過該模塊可以防止ApacheBench 之類壓力測(cè)試工具的攻擊、防止SQL 注入、fuzzing 測(cè)試、XSS、SSRF 等Web攻擊,亦可屏蔽常見的掃描黑客工具,屏蔽異常的網(wǎng)絡(luò)請(qǐng)求、屏蔽圖片附件類目錄php 執(zhí)行權(quán)限、防止webshell上傳等.

遺留系統(tǒng)采用HTTP 協(xié)議開發(fā),HTTP 協(xié)議以明文方式發(fā)送內(nèi)容,不提供任何方式的數(shù)據(jù)加密.如果攻擊者截取了Web 瀏覽器和網(wǎng)站服務(wù)器之間的傳輸報(bào)文,就可以直接讀取其中的信息,特別是在傳輸賬號(hào)密碼這一過程,使得用戶信息存在泄露的可能.采用SSL 加密可以在數(shù)據(jù)傳輸過程進(jìn)行加密,讓用戶信息的安全得到保障.通過在Nginx 配置SSL 證書還可以將HTTP請(qǐng)求強(qiáng)制定向?yàn)楦踩腍TTPS 請(qǐng)求,從而提高系統(tǒng)的安全性.

增加Nginx 中間件可以進(jìn)一步提高系統(tǒng)安全,但是由于系統(tǒng)本身存在的一些漏洞,Nginx 中間件無法全面保護(hù)系統(tǒng).如遺留系統(tǒng)中到處可見的明文GET、POST請(qǐng)求,每一個(gè)參數(shù)都暴露在客戶端,用戶只需要拼接特定的URL 就可以進(jìn)行越權(quán)操作.拼接URL 越權(quán)訪問有兩種方式,分別為橫向越權(quán)和縱向越權(quán).為了防止攻擊者嘗試訪問相同權(quán)限用戶資源的橫向越權(quán)現(xiàn)象發(fā)生,建立用戶和目標(biāo)資源的綁定關(guān)系.只有通過綁定關(guān)系的用戶才可以訪問或者在請(qǐng)求參數(shù)進(jìn)行關(guān)鍵參數(shù)間接映射,避免直接訪問;對(duì)于低權(quán)限越級(jí)訪問高權(quán)限資源的縱向越權(quán),采用RBAC 訪問控制機(jī)制,定義不同角色的訪問權(quán)限,每個(gè)用戶都有特定的權(quán)限,當(dāng)用戶在執(zhí)行某個(gè)動(dòng)作或者進(jìn)行某些行為時(shí),通過角色判定是否允許進(jìn)行操作.此外,將請(qǐng)求路徑和參數(shù)用MD5 算法按一定的規(guī)則進(jìn)行加密,再返回給客戶端處理,防止通過拼接參數(shù)進(jìn)行越權(quán)操作.

3 實(shí)例驗(yàn)證

廣州大學(xué)華軟軟件學(xué)院信息管理系統(tǒng)于2004年開發(fā)建設(shè),現(xiàn)有招生、教務(wù)、科研、財(cái)務(wù)、學(xué)工、人事、后勤七大管理模塊,至今已運(yùn)行16年,累計(jì)源代碼將近60 萬行,涉及數(shù)據(jù)表400 多張,服務(wù)全校15000多名師生.系統(tǒng)開發(fā)時(shí)間早,架構(gòu)技術(shù)較為陳舊,功能模塊之間耦合度高,屬于典型的大型遺留系統(tǒng).隨著用戶量和數(shù)據(jù)量不斷攀升,系統(tǒng)的性能和安全面臨很大的考驗(yàn).根據(jù)系統(tǒng)暴露的問題,結(jié)合本文提出的優(yōu)化方案對(duì)系統(tǒng)進(jìn)行優(yōu)化驗(yàn)證.

前端:從兼容、渲染、規(guī)范、響應(yīng)數(shù)據(jù)等進(jìn)行不同層次的優(yōu)化.優(yōu)化后系統(tǒng)不僅兼容IE9 及以上版本的瀏覽器,在谷歌瀏覽器、火狐瀏覽器等主流瀏覽器下布局也得以改正且可添加主流瀏覽器支持的樣式效果,同時(shí)將JavaScript 代碼更改為通用寫法與短路寫法,在主流瀏覽器下按鈕失效現(xiàn)象也得以解決.在表格布局方面,將table 標(biāo)簽的代碼進(jìn)行重構(gòu),將語義化的標(biāo)簽代替用于布局的table 標(biāo)簽,保留用于展示數(shù)據(jù)表格的table 標(biāo)簽,代碼清晰,方便閱讀,而且網(wǎng)頁從渲染到展示內(nèi)容的速度也得到一定程度的改善.在工程化的思想下進(jìn)行重構(gòu),對(duì)代碼整體進(jìn)行一個(gè)規(guī)范和梳理,文件不僅體積減小而且后期代碼管理也更加便利,同時(shí)對(duì)需要頻繁加載數(shù)據(jù)的頁面采用異步加載進(jìn)行局部更新,服務(wù)器傳輸壓力得以減小且響應(yīng)數(shù)據(jù)的效率也得到相應(yīng)的提高.

數(shù)據(jù)庫:針對(duì)排課、教室資源查詢、考勤登記等響應(yīng)速度較慢的功能模塊進(jìn)行分析與優(yōu)化,找出耗時(shí)較高的SQL 語句,然后重建數(shù)據(jù)庫中涉及相關(guān)表的索引并不定期對(duì)數(shù)據(jù)庫進(jìn)行索引碎片整理,代碼層面則對(duì)業(yè)務(wù)數(shù)據(jù)的存儲(chǔ)邏輯進(jìn)行優(yōu)化.采用JMeter 工具分別對(duì)優(yōu)化前后各模塊的響應(yīng)時(shí)間進(jìn)行測(cè)試與采集,具體如表1所示,可以看出優(yōu)化之后響應(yīng)時(shí)間明顯縮短.

表1 優(yōu)化前后響應(yīng)時(shí)間對(duì)比

服務(wù)器與架構(gòu):主要針對(duì)系統(tǒng)的選課模塊進(jìn)行了優(yōu)化.選課模塊優(yōu)化前存在較大的性能問題,在并發(fā)數(shù)3000 左右就會(huì)出現(xiàn)異?；?qū)е孪到y(tǒng)宕機(jī).現(xiàn)通過服務(wù)器動(dòng)態(tài)擴(kuò)展方式對(duì)選課模塊進(jìn)行優(yōu)化,改變傳統(tǒng)單體應(yīng)用模式,同時(shí)進(jìn)行微服務(wù)化演進(jìn).優(yōu)化之后,用戶并發(fā)數(shù)3000 時(shí)沒有出現(xiàn)異常,逐漸增加用戶數(shù)量后系統(tǒng)表現(xiàn)也較為穩(wěn)定,可以滿足10 000 人同時(shí)選課的需求,并且服務(wù)器內(nèi)存、磁盤IO、CPU 得到了充分的利用,達(dá)到了系統(tǒng)運(yùn)行預(yù)期效果.

安全:優(yōu)化之前我們按照廣東省教育廳公布的《關(guān)于開展信息系統(tǒng)安全等級(jí)保護(hù)工作的通知》的工作要求[13],采用安全掃描工具AppScan 對(duì)系統(tǒng)進(jìn)行掃描,同時(shí)開展了人工滲透測(cè)試,發(fā)現(xiàn)系統(tǒng)存在SSRF、反射型XSS 等諸多中、高危漏洞.結(jié)合本文提出的優(yōu)化方案,通過引入Nginx 中間件,進(jìn)行了HTTPS 的部署升級(jí),解決了通信加密的問題;通過Nginx 過濾,解決了XSS 攻擊、SSRF 漏洞、SQL 注入等問題;通過小跨越的升級(jí)框架版本,解決Apache Struts 歷史漏洞問題.圖6和圖7分別是AppScan 在優(yōu)化之前和之后對(duì)系統(tǒng)進(jìn)行安全掃描的風(fēng)險(xiǎn)圖.

圖6 優(yōu)化前的風(fēng)險(xiǎn)圖

圖7 優(yōu)化后的風(fēng)險(xiǎn)圖

由圖7可以看到優(yōu)化之后已經(jīng)沒有了中、高危風(fēng)險(xiǎn),有效防止黑客模仿用戶身份執(zhí)行不合法行為,證明了安全優(yōu)化方案的有效性.不足之處在于在修補(bǔ)漏洞的同時(shí)衍生了一些低危漏洞,但對(duì)于整體系統(tǒng)而言安全方面提升到了更高一個(gè)等級(jí).

4 結(jié)束語

本文先闡述了大型遺留系統(tǒng)在運(yùn)行過程中可能存在的性能與安全問題,然后在大型遺留系統(tǒng)特定背景下,多角度挖掘遺留系統(tǒng)性能和安全方面的痛點(diǎn),分別從前端、數(shù)據(jù)庫、服務(wù)器、系統(tǒng)架構(gòu)、系統(tǒng)安全五個(gè)方面給出具體優(yōu)化方案,最后通過廣州大學(xué)華軟軟件學(xué)院信息管理系統(tǒng)進(jìn)行了優(yōu)化策略驗(yàn)證.本文優(yōu)化方案具有一定的代表性和典型性,可以有效提高遺留系統(tǒng)的性能與安全等級(jí),對(duì)于大型遺留系統(tǒng)的優(yōu)化改造具有一定參考意義.