面向服務(wù)的測(cè)量船測(cè)控服務(wù)總線系統(tǒng)*

李永剛，李祥明，吳 云，楊海民，毛 文

(中國(guó)衛(wèi)星海上測(cè)控部,江蘇 江陰 214431)

1 引言

測(cè)控計(jì)算機(jī)系統(tǒng)是航天測(cè)量船測(cè)控系統(tǒng)的神經(jīng)中樞，是信息交換、處理和分析的關(guān)鍵單元[1,2]。測(cè)控軟件系統(tǒng)作為測(cè)控計(jì)算機(jī)系統(tǒng)的核心，需要適應(yīng)當(dāng)前我國(guó)航天任務(wù)多樣化、測(cè)控體制不斷拓展、測(cè)控設(shè)備持續(xù)升級(jí)等形勢(shì)，因此對(duì)于其擴(kuò)展性、復(fù)用性、互操作性等要求越來越高[3]。傳統(tǒng)測(cè)控軟件系統(tǒng)是基于構(gòu)件的軟件體系結(jié)構(gòu)，各個(gè)構(gòu)件通常都是緊密耦合在一起的，構(gòu)件之間通過函數(shù)調(diào)用的方式實(shí)現(xiàn)互操作。構(gòu)件調(diào)用時(shí)需要知道被調(diào)用構(gòu)件的位置和技術(shù)細(xì)節(jié)，這使得構(gòu)件的維護(hù)和重復(fù)使用變得非常困難，因?yàn)橐粋€(gè)構(gòu)件中的修改通常會(huì)引發(fā)其他構(gòu)件的修改。面向服務(wù)的體系架構(gòu)SOA(Service Oriented Architecture)是一種粗粒度、松耦合的體系結(jié)構(gòu)，其本質(zhì)上是服務(wù)的集合，服務(wù)間彼此通信，服務(wù)接口作為與服務(wù)實(shí)現(xiàn)分離的實(shí)體而存在，從而服務(wù)實(shí)現(xiàn)能夠在完全不影響服務(wù)使用者的情況下進(jìn)行修改。采用SOA架構(gòu)可以實(shí)現(xiàn)數(shù)據(jù)和資源的共享，由原來建立專有的單一應(yīng)用變?yōu)榻⒏鼮楦呒?jí)和整合的應(yīng)用，充分利用已有的、可以共享和重復(fù)使用的功能。SOA架構(gòu)的提出，為建立一個(gè)靈活可擴(kuò)展的軟件系統(tǒng)[4,5]，對(duì)現(xiàn)有資源合理分配等問題提供了解決思路。

本文在分析測(cè)量船測(cè)控軟件系統(tǒng)基礎(chǔ)上，設(shè)計(jì)了面向服務(wù)的測(cè)量船測(cè)控服務(wù)總線系統(tǒng)架構(gòu)，該架構(gòu)支持“服務(wù)調(diào)度規(guī)則”與“服務(wù)調(diào)度系統(tǒng)”2種服務(wù)調(diào)度模式，并成功實(shí)現(xiàn)了該系統(tǒng)的服務(wù)端、客戶端和服務(wù)調(diào)度，進(jìn)行了2種模式下的服務(wù)調(diào)用性能測(cè)試，驗(yàn)證了系統(tǒng)的有效性。

2 測(cè)量船測(cè)控軟件系統(tǒng)

測(cè)量船測(cè)控軟件系統(tǒng)主要承擔(dān)船內(nèi)各測(cè)控設(shè)備的引導(dǎo)及測(cè)控信息的匯集、處理、交換和顯示等任務(wù)。測(cè)量船測(cè)控軟件系統(tǒng)由測(cè)控支持、外測(cè)處理、遙測(cè)處理、顯示等子系統(tǒng)組成，其中各子系統(tǒng)分別由衛(wèi)星處理系統(tǒng)和火箭處理系統(tǒng)2部分組成[3,6]。

測(cè)控支持子系統(tǒng)主要完成測(cè)控信息的匯集和交換。外測(cè)處理子系統(tǒng)的核心任務(wù)是根據(jù)外測(cè)數(shù)據(jù)獲得足夠精度的目標(biāo)空間位置和運(yùn)動(dòng)參數(shù)(瞬時(shí)站址地平系或地心系彈道參數(shù))，并給出精度評(píng)估結(jié)果。外測(cè)數(shù)據(jù)處理主要是對(duì)原始測(cè)量元素進(jìn)行物理量綱復(fù)原、合理性檢驗(yàn)、數(shù)據(jù)平滑濾波、誤差修正等[6]。這些處理結(jié)果是航天器性能評(píng)定、設(shè)計(jì)改進(jìn)的重要依據(jù)。遙測(cè)處理子系統(tǒng)是對(duì)運(yùn)載火箭和航天器內(nèi)部各種參數(shù)進(jìn)行測(cè)量。對(duì)遙測(cè)數(shù)據(jù)進(jìn)行實(shí)時(shí)處理，可以監(jiān)視航天器飛行過程中內(nèi)部環(huán)境情況、設(shè)備工作狀態(tài)及航天員的生理狀況。分析遙測(cè)數(shù)據(jù)可以評(píng)估航天器的性能，為故障判斷和設(shè)計(jì)改進(jìn)提供依據(jù)[7]。顯示子系統(tǒng)主要收集測(cè)控過程中處理的狀態(tài)信息和測(cè)控信息，經(jīng)過相應(yīng)處理及時(shí)在顯示器上顯示，為決策人員提供依據(jù)和手段。測(cè)控軟件系統(tǒng)作為測(cè)控計(jì)算機(jī)系統(tǒng)的核心，需要適應(yīng)當(dāng)前我國(guó)航天型號(hào)任務(wù)多樣化、測(cè)控體制不斷拓展、測(cè)控設(shè)備持續(xù)升級(jí)等形勢(shì)，因此對(duì)于其擴(kuò)展性、復(fù)用性、互操作性等要求越來越高。

3 SOA

3.1 SOA基本概念

從軟件開發(fā)方法演進(jìn)的角度來看，軟件開發(fā)技術(shù)總的發(fā)展趨勢(shì)是不斷加大軟件模塊的封裝粒度，從而使得軟件模塊間的耦合度減少，SOA的產(chǎn)生是為了適應(yīng)分布式環(huán)境需求的又一種軟件開發(fā)方式。

關(guān)于SOA，目前尚未有一個(gè)統(tǒng)一的、業(yè)界廣泛接受的定義。一般認(rèn)為，SOA是一個(gè)組件模型，它將應(yīng)用程序的不同功能單元——服務(wù)(Service)，通過服務(wù)之間定義良好的接口和契約聯(lián)系起來。所謂服務(wù)，就是精確定義、封裝完善、獨(dú)立于其它服務(wù)所處環(huán)境和狀態(tài)的功能單元。如圖1所示，服務(wù)一般獨(dú)立于具體實(shí)現(xiàn)技術(shù)細(xì)節(jié)，封裝了可復(fù)用的業(yè)務(wù)功能，通常是大粒度業(yè)務(wù)，如業(yè)務(wù)過程、業(yè)務(wù)活動(dòng)等；接口是采用中立方式進(jìn)行定義的，它應(yīng)該獨(dú)立于實(shí)現(xiàn)服務(wù)的硬件平臺(tái)、操作系統(tǒng)和編程語言。這使得構(gòu)建在這樣的系統(tǒng)中的各種服務(wù)可以以一種統(tǒng)一和通用的方式進(jìn)行交互[8 - 10]。

Figure 1 Services and their interfaces圖1 服務(wù)及其接口

3.2 SOA體系架構(gòu)

SOA體系架構(gòu)[11 - 13]中的組件一般包括：

(1) 服務(wù)提供者：服務(wù)提供者即服務(wù)的擁有者，負(fù)責(zé)將服務(wù)信息發(fā)布到服務(wù)注冊(cè)中心，同時(shí)要控制對(duì)服務(wù)的訪問以及服務(wù)的維護(hù)和升級(jí)。

(2) 服務(wù)請(qǐng)求者：實(shí)現(xiàn)服務(wù)的查找與調(diào)用。服務(wù)請(qǐng)求者首先到服務(wù)注冊(cè)中心去查找滿足特定條件的、可獲得的服務(wù)。一旦找到，服務(wù)請(qǐng)求者將綁定到該服務(wù)并對(duì)其進(jìn)行實(shí)際調(diào)用。

(3) 服務(wù)注冊(cè)中心：集中存儲(chǔ)服務(wù)信息，以便于服務(wù)請(qǐng)求者查找。同時(shí)，服務(wù)提供者可以把其所能提供的服務(wù)在服務(wù)注冊(cè)中心進(jìn)行注冊(cè)。

上述3種組件所構(gòu)成的體系架構(gòu)如圖2所示，SOA體系架構(gòu)中包含的操作主要包括：

Figure 2 Architecture of SOA圖2 SOA體系架構(gòu)

(1) 發(fā)布服務(wù)：發(fā)布服務(wù)的描述信息，以便服務(wù)請(qǐng)求者發(fā)現(xiàn)和調(diào)用。

(2) 查詢服務(wù)：服務(wù)請(qǐng)求者通過服務(wù)注冊(cè)中心查找符合其需求的服務(wù)。

(3) 綁定服務(wù)：在獲得服務(wù)描述信息之后，服務(wù)請(qǐng)求者據(jù)此調(diào)用服務(wù)。

4 測(cè)控服務(wù)總線系統(tǒng)設(shè)計(jì)

測(cè)量船測(cè)控軟件系統(tǒng)的設(shè)計(jì)需求包括2部分，對(duì)系統(tǒng)級(jí)的若干全局通用功能進(jìn)行服務(wù)化設(shè)計(jì)，例如軟件調(diào)度功能(軟件啟動(dòng)、軟件退出、主副機(jī)狀態(tài)切換等)、軟件狀態(tài)與參數(shù)設(shè)置(軟件功能選擇、運(yùn)行時(shí)參數(shù)裝訂等)；對(duì)分系統(tǒng)級(jí)的若干局部通用功能進(jìn)行服務(wù)化設(shè)計(jì)，如外測(cè)數(shù)據(jù)處理分系統(tǒng)的電波折射修正與反修正功能、坐標(biāo)系轉(zhuǎn)換功能、軟件參數(shù)設(shè)置功能等。為適應(yīng)系統(tǒng)級(jí)、分系統(tǒng)級(jí)2類層級(jí)不同的服務(wù)化部署要求，兼容實(shí)時(shí)性、擴(kuò)展性、便捷性等需求，本文在吸收借鑒SOA架構(gòu)設(shè)計(jì)理念的基礎(chǔ)上，設(shè)計(jì)了測(cè)量船測(cè)控服務(wù)總線系統(tǒng)架構(gòu)，如圖3所示。

Figure 3 Architecture of TT&C service bus system for survey ship圖3 測(cè)量船測(cè)控服務(wù)總線系統(tǒng)架構(gòu)

測(cè)量船測(cè)控服務(wù)總線系統(tǒng)架構(gòu)為分布式系統(tǒng)中的各個(gè)組件提供了一種透明的通信機(jī)制，服務(wù)端組件通過服務(wù)注冊(cè)、服務(wù)運(yùn)行接口為客戶端組件提供服務(wù)，或者通過服務(wù)請(qǐng)求接口獲取服務(wù)端組件提供的服務(wù)。測(cè)控服務(wù)總線系統(tǒng)架構(gòu)實(shí)現(xiàn)了“服務(wù)調(diào)度規(guī)則”與“服務(wù)調(diào)度系統(tǒng)”2種服務(wù)注冊(cè)與調(diào)用的模式：

(1)“服務(wù)調(diào)度規(guī)則”模式，通過建立全局的服務(wù)調(diào)度規(guī)則，實(shí)現(xiàn)服務(wù)提供方與服務(wù)注冊(cè)方之間對(duì)于服務(wù)規(guī)則約定的一致理解，采用直接交互的方式實(shí)現(xiàn)服務(wù)請(qǐng)求與調(diào)用。優(yōu)點(diǎn)是服務(wù)調(diào)用效率高，適用于實(shí)時(shí)性要求高的應(yīng)用場(chǎng)景，同時(shí)由于沒有中間的服務(wù)管理環(huán)節(jié)，一般架設(shè)于相互信任的服務(wù)端和客戶端之間，適用于單一軟件分系統(tǒng)內(nèi)部。

(2)“服務(wù)調(diào)度系統(tǒng)”模式，該模式下客戶端與服務(wù)端之間需要通過獨(dú)立運(yùn)行的服務(wù)調(diào)度系統(tǒng)進(jìn)行集中調(diào)度。服務(wù)調(diào)度系統(tǒng)負(fù)責(zé)維護(hù)全局統(tǒng)一的服務(wù)路由信息表，將每一個(gè)客戶端發(fā)送的服務(wù)請(qǐng)求與對(duì)應(yīng)的服務(wù)端相匹配，并將服務(wù)運(yùn)行完畢后的回答信息返回給客戶端。除此之外，服務(wù)調(diào)度系統(tǒng)還提供了功能擴(kuò)展的平臺(tái)，可以按需加載服務(wù)安全機(jī)制、服務(wù)監(jiān)控機(jī)制、日志機(jī)制等擴(kuò)展功能。

5 測(cè)控服務(wù)總線系統(tǒng)實(shí)現(xiàn)

基于SOA的測(cè)量船測(cè)控服務(wù)總線系統(tǒng)的實(shí)現(xiàn)包括服務(wù)端、客戶端和服務(wù)調(diào)度。

5.1 服務(wù)端

測(cè)控服務(wù)總線系統(tǒng)為服務(wù)端提供了服務(wù)注冊(cè)、服務(wù)運(yùn)行的接口，使用的關(guān)鍵技術(shù)包括多路復(fù)用技術(shù)和線程池技術(shù)。其中，多路復(fù)用指的是在一個(gè)統(tǒng)一的事件循環(huán)中監(jiān)聽給定的多個(gè)文件描述符，當(dāng)其中某一個(gè)或多個(gè)文件描述符發(fā)生可讀、可寫、關(guān)閉等事件時(shí)，系統(tǒng)會(huì)喚醒事件循環(huán)并給出發(fā)生的事件集合。

麒麟操作系統(tǒng)提供的多路復(fù)用接口函數(shù)為：intepoll_wait(int _epfd,structepoll_event*_events,int_maxevents,int_timeout)，其中_epfd為統(tǒng)一的文件描述符，用來監(jiān)控預(yù)先給定的多個(gè)文件描述符所發(fā)生的事件，_maxevents為每一次事件循環(huán)喚醒時(shí)返回事件個(gè)數(shù)的最大值，_timeout為超時(shí)時(shí)間，為-1時(shí)表示永久等待，直到有事件發(fā)生。當(dāng)函數(shù)返回時(shí)，所發(fā)生的事件集合會(huì)寫入_events參數(shù)。基于麒麟操作系統(tǒng)所提供的多路復(fù)用接口，測(cè)控服務(wù)總線系統(tǒng)會(huì)為每一個(gè)注冊(cè)的服務(wù)生成一個(gè)文件描述符，并將它們加入到epoll_wait的等待隊(duì)列中，當(dāng)客戶端發(fā)來服務(wù)請(qǐng)求時(shí)，對(duì)應(yīng)的文件描述符會(huì)發(fā)生可讀事件，事件循環(huán)線程會(huì)被喚醒并執(zhí)行相應(yīng)的服務(wù)函數(shù)。服務(wù)注冊(cè)、運(yùn)行、請(qǐng)求示意圖如圖4所示。

Figure 4 Registration,operation and request of service圖4 服務(wù)注冊(cè)、運(yùn)行和請(qǐng)求

實(shí)際運(yùn)行環(huán)境中，服務(wù)端需要同時(shí)對(duì)多個(gè)相同或者不同的服務(wù)請(qǐng)求進(jìn)行并發(fā)響應(yīng)，此時(shí)需要用到線程池技術(shù)，通過預(yù)先啟動(dòng)多個(gè)服務(wù)運(yùn)行線程，動(dòng)態(tài)地對(duì)epoll_wait等待的事件集合進(jìn)行細(xì)粒度控制來達(dá)到并發(fā)響應(yīng)或者串行響應(yīng)的效果。此過程中用到的關(guān)鍵系統(tǒng)函數(shù)為：intepoll_ctl(int_epfd,int_op,int_fd,structepoll_event*_event)，其中_epfd和_event的含義與epoll_wait中的參數(shù)含義一致，_fd為需要進(jìn)行細(xì)粒度控制的文件描述符，_op為要對(duì)_fd進(jìn)行的操作類型，可選取值和適用時(shí)機(jī)如下：EPOLL_CTL_ADD表示將_fd加入到_epfd的監(jiān)控列表中，在服務(wù)注冊(cè)時(shí)調(diào)用；EPOLL_CTL_DEL表示將_fd從_epfd的監(jiān)控列表中刪除，在服務(wù)注消時(shí)調(diào)用；EPOLL_CTL_MOD表示更新_fd的狀態(tài)，更新后_epfd才能重新對(duì)_fd進(jìn)行監(jiān)控。

每一次服務(wù)運(yùn)行過程中都需要調(diào)用，對(duì)于并發(fā)服務(wù)，在服務(wù)響應(yīng)函數(shù)執(zhí)行之前調(diào)用該接口，其他線程可以立即響應(yīng)_fd上其他請(qǐng)求，服務(wù)線程池并發(fā)響應(yīng)示意圖如圖5所示。對(duì)于串行服務(wù)，則在服務(wù)響應(yīng)函數(shù)執(zhí)行之后調(diào)用該接口，在服務(wù)函數(shù)的執(zhí)行期間，_epfd不能對(duì)_fd進(jìn)行監(jiān)控，所以其他線程不會(huì)收到_fd上的其他請(qǐng)求。

Figure 5 Concurrent responses of service thread pool圖5 服務(wù)線程池并發(fā)響應(yīng)

5.2 客戶端

測(cè)控服務(wù)總線系統(tǒng)為客戶端提供了2類服務(wù)請(qǐng)求接口，分別為同步請(qǐng)求和異步請(qǐng)求。同步請(qǐng)求會(huì)阻塞請(qǐng)求線程直至服務(wù)端返回結(jié)果，圖4和圖5所示的客戶端部分即為典型的同步請(qǐng)求模式。在異步請(qǐng)求模式下，服務(wù)請(qǐng)求將會(huì)立即返回并繼續(xù)執(zhí)行其他處理過程，由服務(wù)回答異步處理線程進(jìn)行后續(xù)處理，異步請(qǐng)求模式示意圖如圖6所示。在異步請(qǐng)求模式中，對(duì)回答結(jié)果的處理與服務(wù)處理流程一樣，也用到了多路復(fù)用技術(shù)和線程池技術(shù)，可以對(duì)多個(gè)相同或者不同服務(wù)的回答結(jié)果進(jìn)行并行處理。

Figure 6 Asynchronous request mode圖6 異步請(qǐng)求模式

5.3 服務(wù)調(diào)度

測(cè)控服務(wù)總線系統(tǒng)的服務(wù)調(diào)度包含“服務(wù)調(diào)度規(guī)則”和“服務(wù)調(diào)度系統(tǒng)”2種模式。在“服務(wù)調(diào)度規(guī)則”模式下，通信的雙方通過事先約定的路由規(guī)則進(jìn)行匹配，例如使用公開的IP地址和端口，或者使用哈希算法將服務(wù)名字符串計(jì)算為一個(gè)目的地址等方式，該模式適用于互相信任的系統(tǒng)內(nèi)部組件之間，通信效率高。

在“服務(wù)調(diào)度系統(tǒng)”模式下，由服務(wù)調(diào)度系統(tǒng)負(fù)責(zé)維護(hù)全局統(tǒng)一的服務(wù)路由信息表，將每一個(gè)客戶端發(fā)送的服務(wù)請(qǐng)求與對(duì)應(yīng)的服務(wù)端相匹配，并將服務(wù)回答返回給客戶端。服務(wù)調(diào)度系統(tǒng)具備訪問權(quán)限檢查、對(duì)請(qǐng)求來源進(jìn)行安全性過濾、記錄日志等輔助功能?？蛻舳?、服務(wù)端雙方通過服務(wù)調(diào)度系統(tǒng)進(jìn)行通信的處理流程如圖7所示。

6 測(cè)試與驗(yàn)證

本節(jié)對(duì)測(cè)控服務(wù)總線系統(tǒng)分別在“服務(wù)調(diào)度規(guī)則”和“服務(wù)調(diào)度系統(tǒng)”模式下進(jìn)行性能測(cè)試。測(cè)試環(huán)境為聯(lián)想Thinkpad E550筆記本，硬件配置為Intel Core i5 CPU(4核，2.2 GHz),8 GB RAM。

6.1 服務(wù)調(diào)度規(guī)則模式性能測(cè)試

服務(wù)調(diào)度規(guī)則模式性能測(cè)試主要測(cè)試系統(tǒng)在“服務(wù)調(diào)度規(guī)則”模式下的服務(wù)調(diào)用性能，以調(diào)用服務(wù)請(qǐng)求發(fā)出至服務(wù)結(jié)果返回所消耗的時(shí)間為衡量標(biāo)準(zhǔn)。具體測(cè)試方案為：

(1)編寫服務(wù)端測(cè)試程序ServerApp_Rule以提供DemoService服務(wù)。由于測(cè)試對(duì)象為服務(wù)總線系統(tǒng)的性能表現(xiàn)，被測(cè)服務(wù)所提供的具體服務(wù)內(nèi)容與該項(xiàng)測(cè)試無關(guān)，如果服務(wù)本身所消耗的處理時(shí)間過長(zhǎng)，反而將影響測(cè)試結(jié)果所展現(xiàn)的意義，因此對(duì)DemoService服務(wù)進(jìn)行簡(jiǎn)化設(shè)計(jì)，服務(wù)內(nèi)容為將客戶端發(fā)來的整型數(shù)值加1后返回客戶端。

(2)編寫客戶端測(cè)試程序ClientApp_Rule，基于“服務(wù)調(diào)度規(guī)則”模式，通過服務(wù)總線庫(kù)接口請(qǐng)求調(diào)用ServerApp_Rule提供的DemoService服務(wù)，記錄從服務(wù)請(qǐng)求發(fā)出至服務(wù)結(jié)果返回所消耗的時(shí)間，連續(xù)不間斷調(diào)用10萬次并求取時(shí)間平均值。

測(cè)試過程中，通過動(dòng)態(tài)調(diào)整客戶端測(cè)試程序ClientApp_Rule并發(fā)請(qǐng)求服務(wù)的線程數(shù)量，來模擬并發(fā)請(qǐng)求DemoService服務(wù)的客戶數(shù)量，動(dòng)態(tài)調(diào)整服務(wù)端測(cè)試程序ServerApp_Rule的服務(wù)線程池規(guī)模來模擬服務(wù)實(shí)例的數(shù)量。測(cè)試結(jié)果如表1所示。從測(cè)試結(jié)果的縱向變化趨勢(shì)來看，如果保持服務(wù)實(shí)例的數(shù)量不變，隨著客戶數(shù)量的增加，調(diào)用時(shí)間呈現(xiàn)線性遞增趨勢(shì)，表明調(diào)用性能逐漸降低，符合多客戶爭(zhēng)搶資源帶來性能下降的預(yù)期。

Table 1 Performance test results of service scheduling rule pattern表1 服務(wù)調(diào)度規(guī)則模式性能測(cè)試結(jié)果

從測(cè)試結(jié)果的橫向變化趨勢(shì)來看，如果保持客戶數(shù)量不變，隨著服務(wù)實(shí)例數(shù)量的增加，調(diào)用時(shí)間整體呈下降趨勢(shì)，表明調(diào)用性能趨于優(yōu)化，但是優(yōu)化的程度隨線程增加趨于減弱。定性分析其原因，在于所測(cè)試的DemoService服務(wù)本身消耗資源極小，當(dāng)線程數(shù)量達(dá)到一定規(guī)模后(超過測(cè)試機(jī)器CPU內(nèi)核數(shù)量并繼續(xù)增加)，其帶來的性能優(yōu)化被CPU頻繁的線程切換工作帶來的損耗所抵消。

整體上看，單次服務(wù)調(diào)用所消耗的時(shí)間在0.1 ms量級(jí)，結(jié)合實(shí)際應(yīng)用情況，系統(tǒng)在“服務(wù)調(diào)度規(guī)則”模式下的性能表現(xiàn)顯然能夠滿足應(yīng)用要求。本文在開源企業(yè)服務(wù)總線Jboss ESB、Mule ESB、ServiceMix ESB和Synapse ESB上分別做了相應(yīng)的性能測(cè)試，結(jié)果統(tǒng)計(jì)都相差不多。但是，結(jié)合自主可控和安全性，以及對(duì)國(guó)產(chǎn)麒麟操作系統(tǒng)的適應(yīng)性，本文設(shè)計(jì)的系統(tǒng)更可取。

6.2 服務(wù)調(diào)度系統(tǒng)模式性能測(cè)試

服務(wù)調(diào)度系統(tǒng)模式性能測(cè)試主要測(cè)試系統(tǒng)在“服務(wù)調(diào)度系統(tǒng)”模式下的服務(wù)調(diào)用性能，以調(diào)用服務(wù)請(qǐng)求發(fā)出至服務(wù)結(jié)果返回所消耗的時(shí)間為衡量標(biāo)準(zhǔn)。具體測(cè)試方案為：

(1) 編寫服務(wù)端測(cè)試程序ServerApp_System以提供DemoService服務(wù)；

(2) 編寫調(diào)度代理測(cè)試程序AgentApp轉(zhuǎn)發(fā)DemoService服務(wù)調(diào)度請(qǐng)求與返回結(jié)果，不進(jìn)行IP地址過濾等安全性檢測(cè)，AgentApp采用“單線程接收服務(wù)請(qǐng)求，單線程返回服務(wù)結(jié)果”的軟件架構(gòu)；

(3) 編寫客戶端測(cè)試程序ClientApp_System，基于“服務(wù)調(diào)度系統(tǒng)”模式，通過服務(wù)總線庫(kù)接口請(qǐng)求調(diào)用ServerApp_System提供的Demo- Service服務(wù)，記錄從服務(wù)請(qǐng)求發(fā)出至服務(wù)結(jié)果返回所消耗的時(shí)間，連續(xù)不間斷調(diào)用10萬次并求取時(shí)間平均值。

測(cè)試過程中，通過動(dòng)態(tài)調(diào)整客戶端測(cè)試程序ClientApp_System并發(fā)請(qǐng)求服務(wù)的線程數(shù)量，來模擬并發(fā)請(qǐng)求DemoService服務(wù)的客戶數(shù)量，動(dòng)態(tài)調(diào)整服務(wù)端測(cè)試程序ServerApp_System的服務(wù)線程池規(guī)模來模擬服務(wù)實(shí)例的數(shù)量。測(cè)試結(jié)果如表2所示。

Table 2 Performance test results of service scheduling system pattern表2 服務(wù)調(diào)度系統(tǒng)模式性能測(cè)試結(jié)果

從測(cè)試結(jié)果的縱向變化趨勢(shì)來看，如果保持服務(wù)實(shí)例的數(shù)量不變，隨著客戶數(shù)量的增加，調(diào)用時(shí)間呈現(xiàn)線性遞增趨勢(shì)，表明調(diào)用性能逐漸降低，符合多客戶爭(zhēng)搶資源帶來性能下降的預(yù)期。同時(shí)，該測(cè)試結(jié)果明顯高于表1中相對(duì)應(yīng)的測(cè)試結(jié)果，這是因?yàn)椤胺?wù)調(diào)度系統(tǒng)”模式下，服務(wù)請(qǐng)求的發(fā)出和服務(wù)結(jié)果的返回均需經(jīng)過AgentApp的轉(zhuǎn)發(fā)處理，增加了時(shí)間消耗。

從測(cè)試結(jié)果的橫向變化趨勢(shì)來看，如果保持客戶數(shù)量不變，隨著服務(wù)實(shí)例數(shù)量的增加，調(diào)用時(shí)間下降不明顯，表明調(diào)度性能的優(yōu)化效果較為微弱。經(jīng)過進(jìn)一步測(cè)試和分析發(fā)現(xiàn)，該模式下負(fù)責(zé)服務(wù)調(diào)度請(qǐng)求和服務(wù)結(jié)果轉(zhuǎn)發(fā)的AgentApp已經(jīng)成為消耗時(shí)間較多的瓶頸環(huán)節(jié)，這也與AgentApp“單線程接收，單線程發(fā)送”架構(gòu)存在關(guān)系。

整體上看，單次服務(wù)調(diào)用所消耗的時(shí)間在1 ms量級(jí)，結(jié)合實(shí)際應(yīng)用情況，系統(tǒng)在服務(wù)調(diào)度系統(tǒng)模式下的性能表現(xiàn)能夠滿足應(yīng)用要求。本文在開源企業(yè)服務(wù)總線Jboss ESB、Mule ESB、ServiceMix ESB和Synapse ESB上分別做了相應(yīng)的性能測(cè)試，結(jié)果統(tǒng)計(jì)都相差不多。但是，結(jié)合自主可控和安全性，以及對(duì)國(guó)產(chǎn)麒麟操作系統(tǒng)的適應(yīng)性，本文設(shè)計(jì)的系統(tǒng)更可取。

7 結(jié)束語

本文在分析測(cè)量船測(cè)控軟件系統(tǒng)的基礎(chǔ)上，針對(duì)現(xiàn)有系統(tǒng)復(fù)雜性高、不易擴(kuò)展和維護(hù)的現(xiàn)狀，設(shè)計(jì)了面向服務(wù)的測(cè)量船測(cè)控服務(wù)總線系統(tǒng)架構(gòu)，支持2種服務(wù)調(diào)度模式，包括“服務(wù)調(diào)度規(guī)則”與“服務(wù)調(diào)度系統(tǒng)”，實(shí)現(xiàn)了系統(tǒng)服務(wù)端和客戶端。測(cè)試結(jié)果表明：該系統(tǒng)能夠充分保證2種模式下的服務(wù)調(diào)用性能，對(duì)提高測(cè)量船測(cè)控軟件系統(tǒng)的效率具有重要意義。