一種云計算環(huán)境下的Web服務(wù)質(zhì)量探測與預(yù)警方法

張上++江超

摘要：伴隨著互聯(lián)網(wǎng)絡(luò)的發(fā)展，具有相同功能不同服務(wù)質(zhì)量的Web服務(wù)隨之大量涌現(xiàn)。服務(wù)質(zhì)量成為客戶選擇服務(wù)的重要依據(jù)，與企業(yè)的盈利息息相關(guān)。然而當前的Web服務(wù)常面向全國范圍，對于企業(yè)的運維來說如何監(jiān)控全國各地區(qū)的客戶訪問Web服務(wù)的質(zhì)量，并在出現(xiàn)問題時，第一時間向運維人員預(yù)警，成為亟待解決的問題。為此本文以分布于全國各地區(qū)的云基礎(chǔ)設(shè)施服務(wù)為依托，使用RPC分布式遠程調(diào)用技術(shù)，針對以上問題，實現(xiàn)了一種云計算環(huán)境下Web服務(wù)質(zhì)量探測與預(yù)警方法。

關(guān)鍵詞：云計算； Web服務(wù)； 服務(wù)質(zhì)量

中圖分類號： TP393.02

文獻標志碼：A

文章編號： 2095-2163（2016）06-0051-04

0引言

隨著互聯(lián)網(wǎng)絡(luò)的發(fā)展，Web服務(wù)隨之大量涌現(xiàn)。所謂Web服務(wù)是指一種通過互聯(lián)網(wǎng)絡(luò)提供自描述的自適應(yīng)的模塊化的軟件組件，可以在互聯(lián)網(wǎng)絡(luò)中得到描述、發(fā)現(xiàn)和調(diào)用＼[1＼]。Web服務(wù)一般依托于Web服務(wù)應(yīng)用程序進行發(fā)布和管理，通過聚類不同的Web服務(wù)可以構(gòu)成功能復(fù)雜的組合服務(wù)，以此來滿足當前企業(yè)日益繁多的事務(wù)邏輯需求。然而隨著Web服務(wù)技術(shù)的成熟，互聯(lián)網(wǎng)上開始出現(xiàn)大量功能相近的服務(wù)，此時服務(wù)質(zhì)量就必然成為客戶選擇相關(guān)Web服務(wù)的重要依據(jù)。而Web服務(wù)的目標常為全國范圍的對象，那么如何在不同地區(qū)探測企業(yè)Web服務(wù)的質(zhì)量，并對服務(wù)質(zhì)量不滿足構(gòu)建提供及時預(yù)警，即已成為目前亟待解決的關(guān)鍵問題?；诖?，本文即依托于分布在全國不同區(qū)域的云計算基礎(chǔ)設(shè)施，使用RPC分布式遠程過程調(diào)用框架，研發(fā)設(shè)計了一種云環(huán)境下Web服務(wù)質(zhì)量的探測與預(yù)警方法。

[BT4]1相關(guān)工作

時下，有關(guān)Web服務(wù)質(zhì)量的研究多是圍繞Web服務(wù)質(zhì)量預(yù)測方向延伸展開。而對于Web服務(wù)質(zhì)量的預(yù)測，Shao等針對未使用過的Web服務(wù)的服務(wù)質(zhì)量，率先提出使用協(xié)同過濾策略，進行Web服務(wù)質(zhì)量預(yù)測的方法＼[2＼]。[JP3]在此基礎(chǔ)上，Zheng等致力于技術(shù)改進，繼而提出了一種基于鄰接矩陣分解的混合協(xié)同過濾算法的Web質(zhì)量預(yù)測方法＼[3＼]。Luo等又通過結(jié)合模糊神經(jīng)網(wǎng)絡(luò)和自適應(yīng)動態(tài)規(guī)劃重點實現(xiàn)了更加穩(wěn)定和較為精確的服務(wù)質(zhì)量預(yù)測＼[4＼]。而Ma等則基于真實的Web服務(wù)質(zhì)量數(shù)據(jù)和一系列實驗，確定了服務(wù)質(zhì)量相關(guān)的特征指標。通過這些指標可以增加服務(wù)質(zhì)量預(yù)測的精度＼[5＼]。另外，還有Madi等又通過進一步使用概率的潛在模型來統(tǒng)計服務(wù)質(zhì)量的相關(guān)預(yù)測＼[6＼]。綜上研究發(fā)現(xiàn)，目前大部分的研究內(nèi)容仍然是以預(yù)測為主，卻尚未推出一種能夠在不同地理位置對于某類Web服務(wù)的服務(wù)質(zhì)量進行實時監(jiān)測和預(yù)警的方法，為此本文即有針對性地設(shè)計提出了一種依托云計算基礎(chǔ)設(shè)施的Web服務(wù)質(zhì)量的實時監(jiān)控和預(yù)警方法。[JP]

[BT4]2系統(tǒng)設(shè)計

[BT5]2.1整體框架設(shè)計

為實現(xiàn)分布式的Web服務(wù)質(zhì)量的探測和預(yù)警，本次研發(fā)系統(tǒng)可由以下模塊建設(shè)構(gòu)成：服務(wù)質(zhì)量探測模塊、遠程過程調(diào)用模塊、電子郵件告警模塊、數(shù)據(jù)庫存儲模塊、報表生成模塊。系統(tǒng)中模塊間的關(guān)系與架構(gòu)則如圖1所示。[FL）]

為在不同地區(qū)能夠有效支持做到對于Web服務(wù)質(zhì)量的探測與預(yù)警，需要向云計算基礎(chǔ)設(shè)施服務(wù)提供商在不同地區(qū)租用服務(wù)器，以阿里云為例，其可選的地區(qū)在華北、華東有2個，在華南、香港、新加坡、美國西部與美國東部則各有一個。其他的基礎(chǔ)設(shè)施提供商所指定的位置也不盡相同，因此可通過在不同地區(qū)租用不同的服務(wù)器，實現(xiàn)多區(qū)域的Web服務(wù)質(zhì)量的探測，在主控端加入預(yù)警閾值，當達到閾值時，系統(tǒng)即會通過電子郵件向運維人員發(fā)出預(yù)警提示。

2.2功能模塊設(shè)計

該系統(tǒng)整體主要包含5個功能模塊，各模塊間的互聯(lián)關(guān)系已由圖1呈現(xiàn)給出，在此將針對每種功能模塊的現(xiàn)實優(yōu)化設(shè)計展開如下解析描述：

1）探測模塊。主要功能是在不同區(qū)域租用的服務(wù)器上，完成對于目標系統(tǒng)的服務(wù)質(zhì)量探測功能，其具體獲取與服務(wù)質(zhì)量相關(guān)數(shù)據(jù)包括：DNS解析時間、連接建立時間、傳輸準備時間、傳輸起始時間、傳輸總時間、http狀態(tài)、傳輸數(shù)據(jù)包大小、頭數(shù)據(jù)大小、請求包大小、傳輸內(nèi)容長度、傳輸速度、測試時間。該模塊可以由主控模塊通過RPC協(xié)議控制調(diào)用，并將采集結(jié)果傳回主控模塊。

2）數(shù)據(jù)庫模塊。該模塊一般使用傳統(tǒng)的Mysql數(shù)據(jù)庫，其定制功能是將探測到的數(shù)據(jù)以歷史記錄的形式存儲起來，以供后期的服務(wù)質(zhì)量分析使用。模塊中主要涉及的表結(jié)構(gòu)有2個，分別如表1、表2所示。

3）RRDTOOL數(shù)據(jù)庫模塊。該模塊的主要功能就是通過跟蹤目標對象相關(guān)參數(shù)的變化情況，繼而將這些變化生成實時數(shù)據(jù)圖，并推送給運維人員。RRDTOOL其實是一種環(huán)狀的數(shù)據(jù)庫，運行時是通過Round Robin的方式來處理定量數(shù)據(jù)，當前已被多家流行的平臺采納使用，例如：Ganglia、Cacti和Monitorix等等。

4）電子郵件模塊。該模塊的主要功能是向運維人員發(fā)送郵件，以提醒運維人員已出現(xiàn)的告警類型，請求運維人員介入調(diào)控。在這里，研究使用了Python的smtplib模塊完成郵件功能的發(fā)送。

5）主控模塊。該模塊的主要功能是通過RPC遠程過程調(diào)用方法，[JP2]調(diào)用已部署到租用云服務(wù)器中的探測模塊，進行Web服務(wù)質(zhì)量的探測。同時，還將負責(zé)接收探測模塊發(fā)來的探測結(jié)果數(shù)據(jù)，調(diào)用數(shù)據(jù)庫模塊將數(shù)據(jù)保存到數(shù)據(jù)庫中，并更新RRDTOOL數(shù)據(jù)庫信息。最后依據(jù)探測任務(wù)設(shè)定的告警條件和告警類型，確定是否需要向運維人員發(fā)出告警。如果需要，則調(diào)用電子郵件模塊，生成告警郵件并將其發(fā)送至告警郵箱。[JP]

[BT5]2.3通信協(xié)議設(shè)計

在通信過程中重點啟用了RPC遠程過程調(diào)用協(xié)議。RPC（Remote Procedure Call Protocol）是一種流行的遠程過程調(diào)用協(xié)議，其主要功能可描述為就是通過網(wǎng)絡(luò)向遠程服務(wù)器上應(yīng)用程序請求程序調(diào)用服務(wù)，而無需精確了解底層的網(wǎng)絡(luò)協(xié)議或拓撲結(jié)構(gòu)。在RPC協(xié)議中，請求端（又稱為客戶）在設(shè)定的傳輸協(xié)議下，發(fā)送一段帶有參數(shù)的信息到服務(wù)提供端。此時服務(wù)提供端配備的服務(wù)提供應(yīng)用程序，在接收到該參數(shù)后將會進行設(shè)計指定的解析操作，并依照解析結(jié)果，調(diào)用相關(guān)的功能模塊執(zhí)行請求操作。當完成操作后，再將函數(shù)調(diào)用結(jié)果返回給請求端的調(diào)用程序。

圖2為RPC遠程過程調(diào)用的流程圖。從圖2中可知，遠程過程調(diào)用整體上可以分為10步，對其概述如下：

1）主控模塊調(diào)用客戶端句柄進行參數(shù)傳遞，參數(shù)如：探測任務(wù)的ID和探測的目標；

2）客戶端句柄調(diào)用客戶端服務(wù)器操作系統(tǒng)內(nèi)核的網(wǎng)絡(luò)模塊，生成輸出參數(shù)編碼和數(shù)據(jù)發(fā)送操作；

3）參數(shù)數(shù)據(jù)通過網(wǎng)絡(luò)發(fā)送到遠程服務(wù)器（即所租用的云服務(wù)器）操作系統(tǒng)內(nèi)核的網(wǎng)絡(luò)模塊；

4）遠程服務(wù)端的服務(wù)器句柄獲得參數(shù)數(shù)據(jù)并解析出其中的參數(shù)；

5）遠程服務(wù)器句柄依據(jù)獲取到的參數(shù)，調(diào)用探測模塊的相關(guān)函數(shù)，切換至探測任務(wù)；

6）探測模塊將執(zhí)行結(jié)果返回給作為調(diào)用方的遠程服務(wù)器句柄；

[LL]

7）遠程服務(wù)器句柄調(diào)用該服務(wù)器操作系統(tǒng)內(nèi)核的網(wǎng)絡(luò)模塊進行結(jié)果數(shù)據(jù)的編碼和數(shù)據(jù)發(fā)送操作；

8）探測數(shù)據(jù)通過網(wǎng)絡(luò)發(fā)送給客戶端服務(wù)器操作系統(tǒng)內(nèi)核的網(wǎng)絡(luò)模塊；

9）客戶端服務(wù)器的服務(wù)器句柄接收探測數(shù)據(jù)并送入解析處理；

10）客戶端服務(wù)器句柄將解析后的數(shù)據(jù)以函數(shù)值的形式返回給主控模塊，從而完成整個遠程服務(wù)調(diào)用過程。

3云環(huán)境下實驗驗證

[BT5]3.1實驗環(huán)境

實驗的本地部分由超云R6240-G9刀片服務(wù)器的4個物理節(jié)點構(gòu)成，其中每個節(jié)點的配置信息為：CPU為24核，內(nèi)存為32GB，硬盤2T，千兆網(wǎng)卡。[JP2]而4個服務(wù)器上將分別部署主控模塊、數(shù)據(jù)塊模塊、RRDTOOL數(shù)據(jù)庫模塊和電子郵件模塊。探測服務(wù)器為租用的阿里云服務(wù)器，同時選擇華北1（青島市）、華北2（北京市）、華東1（杭州市）和華南1（深圳市）的云服務(wù)器各一臺，每種服務(wù)器都選擇最低配置的ecs.t1.small類型，[JP]該類型具有單核CPU和2GB內(nèi)存，以及百兆帶寬。測試的目標為哈爾濱工業(yè)大學(xué)網(wǎng)站的首頁，可得該網(wǎng)站的URL為：www.hit.edu.cn。

[BT5]3.2實驗結(jié)果

實驗結(jié)果即為各質(zhì)量監(jiān)控點采集到的監(jiān)控數(shù)據(jù)，其中以杭州地區(qū)的數(shù)據(jù)質(zhì)量監(jiān)控數(shù)據(jù)為例進行說明，如圖3所示。

由圖3可知，杭州地區(qū)訪問校園網(wǎng)首頁的傳輸總時間、連接建立時間和DNS解析時間都相對比較穩(wěn)定。在某些時刻DNS的解析時間為0，這是由于DNS解析是可以被緩存造成的。圖4則為從阿里云租用的4個不同城市的服務(wù)器中采集到的質(zhì)量信息數(shù)據(jù)。由于不同地區(qū)與目標系統(tǒng)之間經(jīng)過的網(wǎng)絡(luò)路徑不同，因此最終得到的訪問質(zhì)量也相差較大。

4結(jié)束語

通過在阿里云環(huán)境下租用4臺不同地區(qū)的云服務(wù)器進行測試，由此提出了系統(tǒng)在不同地區(qū)分布式探測Web服務(wù)質(zhì)量的思想，并證明了不同地區(qū)、同一Web服務(wù)的服務(wù)質(zhì)量可能存在差異，這就使得租用不同云基礎(chǔ)設(shè)施服務(wù)商不同地區(qū)的服務(wù)器，進行Web服務(wù)質(zhì)量的實時監(jiān)控具備了高度可行的現(xiàn)實必要性。

參考文獻： SHAIKH A. The impact of SOA on a system design for a telemedicine [JP3]healthcare system[J]. Network Modeling Analysis in Health Informatics & Bioinformatics， 2015， 4（1）：1-16.[JP]

[2]SHAO L， ZHANG J， WEI Y， et al. Personalized QoS prediction for Web Services via collaborative filtering[C]// IEEE International Conference on Web Services. Salt Lake City， Utah， USA：IEEE， 2007：439-446.

[3]ZHENG Z， MA H， LYU M R， et al. Collaborative Web Service QoS prediction via neighborhood integrated matrix factorization[J]. IEEE Transactions on Services Computing， 2013， 6（3）：289-299.

[4]LUO X， LV Y， LI R， et al. Web service QoS prediction based on adaptive dynamic programming using fuzzy neural networks for cloud services[J]. Access IEEE， 2015， 3：2260-2269.

[5]MA Y， WANG S， HUNG P C K， et al. A highly accurate prediction algorithm for unknown Web service QoS values[J]. IEEE Transactions on Services Computing， 2016， 9（4）：511-523.

[6]MADI B M A， SHENG Q Z， YAO L， et al. PLMwsp： Probabilistic latent model for Web Service QoS prediction[C]// IEEE International Conference on Web Services. San Francisco，USA：IEEE Computer Society， 2016：623-630.[ZK）]