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

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

1 引言

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

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

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

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

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

3 SOA

3.1 SOA基本概念

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

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

Figure 1 Services and their interfaces圖1 服務及其接口

3.2 SOA體系架構(gòu)

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

(1) 服務提供者：服務提供者即服務的擁有者，負責將服務信息發(fā)布到服務注冊中心，同時要控制對服務的訪問以及服務的維護和升級。

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

(3) 服務注冊中心：集中存儲服務信息，以便于服務請求者查找。同時，服務提供者可以把其所能提供的服務在服務注冊中心進行注冊。

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

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

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

(2) 查詢服務：服務請求者通過服務注冊中心查找符合其需求的服務。

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

4 測控服務總線系統(tǒng)設(shè)計

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

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

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

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

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

5 測控服務總線系統(tǒng)實現(xiàn)

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

5.1 服務端

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

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

Figure 4 Registration,operation and request of service圖4 服務注冊、運行和請求

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

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

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

5.2 客戶端

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

Figure 6 Asynchronous request mode圖6 異步請求模式

5.3 服務調(diào)度

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

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

6 測試與驗證

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7 結(jié)束語

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