分布式服務(wù)架構(gòu)在信號處理系統(tǒng)中的應(yīng)用

文 豪，葉江峰，孫 磊，吳 輝

(中國工程物理研究院 電子工程研究所，四川 綿陽 621900)

0 引言

隨著信息化進(jìn)程的加快，電磁環(huán)境的日趨復(fù)雜，新的信號體制及應(yīng)用需求層出不窮，以往那種功能單一、靈活性不足的無線電信號處理系統(tǒng)已遠(yuǎn)不能適應(yīng)當(dāng)前靈活多變的應(yīng)用需求[1]。為此，軟件無線電(SDR)技術(shù)從20世紀(jì)90年代以后逐漸興起[2]。其思想是通過構(gòu)造一個具有開放性、標(biāo)準(zhǔn)化和模塊化的通用硬件平臺，使無線通信系統(tǒng)具有高度靈活性、開放性[3]。由此，美軍通過聯(lián)合戰(zhàn)術(shù)無線電系統(tǒng)(JTRS)制定了軟件體系結(jié)構(gòu)(SCA)規(guī)范[4]，該標(biāo)準(zhǔn)體系結(jié)構(gòu)為開發(fā)提供統(tǒng)一的、開放式的底層支持和服務(wù)，保證了軟件組件的可移植性和可重用性[5]。但SCA規(guī)范僅能用于指導(dǎo)軟件無線電通信系統(tǒng)整體的設(shè)計開發(fā)，并沒有給出具體的實現(xiàn)方法。目前，大多數(shù)SCA波形組件開發(fā)方法都較為繁瑣復(fù)雜，技術(shù)門檻較高，由此勢必給波形開發(fā)人員帶來很大的開發(fā)難度，造成開發(fā)周期延長、開發(fā)成本上升和測試工作量顯著增加等問題[6]。同時，傳統(tǒng)波形組件不滿足分布式部署與跨平臺等需求，并不適用于搭建原理性的驗證系統(tǒng)。

針對上述問題，本文引入SOA(Service Oriented Architecture)的設(shè)計理念，將其應(yīng)用于信號處理領(lǐng)域，采用更加簡潔優(yōu)秀的ICE(Internet Communications Engine)中間件技術(shù)構(gòu)建出新的信號處理系統(tǒng)架構(gòu)模型。該模型不僅具有很好的可移植性和可重用性，還具備自動化服務(wù)組件封裝能力，極大簡化了組件開發(fā)過程。

另一方面，隨著集群技術(shù)的發(fā)展，以通用的計算機(jī)平臺來替代專用的DSP和FPGA等硬件來進(jìn)行軟件數(shù)字信號處理也成為業(yè)界熱門的研究方向[7]。本文設(shè)計采用“分布式”的服務(wù)架構(gòu)，解決并行化處理、平臺異構(gòu)等問題，使系統(tǒng)能通過增加處理節(jié)點(diǎn)提高處理能力，以滿足大數(shù)據(jù)量信號處理的實時性要求。

1 基于服務(wù)架構(gòu)的信號處理系統(tǒng)模型

1.1 系統(tǒng)架構(gòu)分析及特點(diǎn)

系統(tǒng)的分層體系結(jié)構(gòu)參考模型如圖1所示，其主要包括：軟硬件資源、分布式服務(wù)總線、服務(wù)集成開發(fā)環(huán)境、基礎(chǔ)服務(wù)層、服務(wù)組件層、業(yè)務(wù)服務(wù)層和應(yīng)用系統(tǒng)層。

圖1 模型分層體系結(jié)構(gòu)

軟硬件資源：為實現(xiàn)最大的性能提升及硬件擴(kuò)展能力，模型支持相對復(fù)雜軟硬件資源，主要包括數(shù)據(jù)庫、分布式文件系統(tǒng)、GPP資源和GPU資源等。這些資源用來為系統(tǒng)提供計算資源、數(shù)據(jù)存取資源，支撐上層各類服務(wù)和應(yīng)用的運(yùn)行。

分布式服務(wù)總線：作為服務(wù)框架的核心組成，主要負(fù)責(zé)適配并連接各服務(wù)組件執(zhí)行系統(tǒng)業(yè)務(wù)功能，包括服務(wù)管理、服務(wù)注冊中心、基礎(chǔ)數(shù)據(jù)服務(wù)、接口適配和消息分發(fā)(基于ZeroMQ)等模塊。

服務(wù)集成開發(fā)環(huán)境：服務(wù)組件開發(fā)工具。支持C++語言框架代碼自動生成，幫助開發(fā)者完成服務(wù)的開發(fā)。更重要的是能夠?qū)崿F(xiàn)Matlab文件的服務(wù)自動轉(zhuǎn)換，直接生成滿足ICE接口規(guī)范的服務(wù)發(fā)布包。

基礎(chǔ)服務(wù)層：由各種基礎(chǔ)服務(wù)組成，包括數(shù)據(jù)分發(fā)、數(shù)據(jù)存儲、數(shù)據(jù)源、異常處理和資源調(diào)度等。其主要作用是通過服務(wù)封裝把軟硬件資源抽象成服務(wù)對象，使調(diào)用者不必關(guān)心底層驅(qū)動和數(shù)據(jù)管理。

服務(wù)組件層：服務(wù)組件是開發(fā)人員需要自行設(shè)計實現(xiàn)的最小系統(tǒng)組成單元，通常為不可以再拆分且可復(fù)用的算法單元。應(yīng)用服務(wù)集成開發(fā)環(huán)境可實現(xiàn)服務(wù)組件的快速開發(fā)。

業(yè)務(wù)服務(wù)層：通常由服務(wù)組件組合而成，通過組合和流程編排形成業(yè)務(wù)服務(wù)(也稱為組合服務(wù))，實現(xiàn)具體的業(yè)務(wù)功能。

應(yīng)用系統(tǒng)層：作為直接面向用戶的應(yīng)用系統(tǒng)，接收來自服務(wù)端的推送信息予以顯示。用戶界面開發(fā)采用了QT插件框架技術(shù)，可實現(xiàn)界面的靈活布局，具備良好擴(kuò)展性和跨平臺能力。

分布式服務(wù)架構(gòu)擁有以下特性：

簡便的開發(fā)過程：可以對符合格式規(guī)范的算法源代碼進(jìn)行直接的服務(wù)轉(zhuǎn)化，而不用針對該平臺重新設(shè)計開發(fā)服務(wù)組件，極大地降低了系統(tǒng)開發(fā)難度，也節(jié)省了開發(fā)時間。

多語言支持：通過使用標(biāo)準(zhǔn)的接口定義，使得服務(wù)組件支持C++，Matlab，Java語言開發(fā)。

跨平臺特性：服務(wù)組件可以運(yùn)行在不同的操作系統(tǒng)和機(jī)器架構(gòu)上，并且可以使用多種網(wǎng)絡(luò)協(xié)議進(jìn)行通信。

良好的系統(tǒng)伸縮性：服務(wù)組件可任意分布在多個服務(wù)器上，系統(tǒng)的最大運(yùn)算效率可以隨著系統(tǒng)硬件資源的增加而提高。

整體而言，該架構(gòu)具有良好的開放性，能夠適應(yīng)將來的業(yè)務(wù)拓展需求，有效地提高服務(wù)利用率，減少開發(fā)成本。

1.2 服務(wù)組件的封裝

新信號處理系統(tǒng)的研發(fā)，通常需要在Matlab仿真基礎(chǔ)上，再進(jìn)行軟件應(yīng)用程序的開發(fā)或者硬件設(shè)備的研制，從而評估新系統(tǒng)架構(gòu)的合理性[8]。但這一過程通常需要多次迭代，使得這種研發(fā)模式面臨著周期長、成本高的困境。本文設(shè)計了一種名為“服務(wù)集成開發(fā)環(huán)境”的軟件，可方便地把C++和Matlab程序轉(zhuǎn)化為服務(wù)組件，部署于分布式服務(wù)架構(gòu)中就可快速驗證系統(tǒng)的可行性。

因為ICE本身對C++具有良好的支持[9]，通過C++源代碼生成服務(wù)組件，本文不做贅述。而Matlab卻是信號處理領(lǐng)域?qū)崿F(xiàn)系統(tǒng)仿真應(yīng)用最多的工具，所以，解決Matlab程序的服務(wù)快速開發(fā)才是簡化組件開發(fā)的關(guān)鍵。Matlab程序轉(zhuǎn)化的服務(wù)包封裝結(jié)構(gòu)如圖2所示。

圖2 Matlab程序轉(zhuǎn)化的服務(wù)包封裝結(jié)構(gòu)

Matlab程序轉(zhuǎn)化的服務(wù)包封裝的步驟如下：

① 為實現(xiàn)服務(wù)的轉(zhuǎn)化，Matlab程序編寫必須符合一定規(guī)范，其具體函數(shù)形式如下：

function[strRes，Output1，...] = 函數(shù)名(Input1，Input2，Input3，...)

函數(shù)參數(shù)被分別定義為輸出參數(shù)、輸入?yún)?shù)和配置參數(shù)。輸出參數(shù)在等號左側(cè)，strRes被定義為調(diào)試信息輸出結(jié)構(gòu)體；輸入?yún)?shù)在等號右側(cè)；配置參數(shù)也是輸入?yún)?shù)，但在注釋中加入了Config關(guān)鍵字用來識別。

② 本文設(shè)計的服務(wù)集成開發(fā)環(huán)境會對文件內(nèi)容及注釋信息進(jìn)行格式檢查，對滿足規(guī)范的文件則調(diào)用Matlab自帶的mcc編譯器，編譯出符合C語言規(guī)范的DLL文件及頭文件形成一層封裝。

③ 實現(xiàn)DLL文件向ICE服務(wù)轉(zhuǎn)化。這個過程比較復(fù)雜，但最關(guān)鍵的就是數(shù)據(jù)類型的轉(zhuǎn)化。我們知道，Matlab所有的計算都基于一種名為mxArray的數(shù)據(jù)結(jié)構(gòu)，雖然Matlab提供了數(shù)據(jù)轉(zhuǎn)換函數(shù)mlfScalar()和mxGetPr()，但其依賴Matlab環(huán)境，不便于系統(tǒng)獨(dú)立運(yùn)行。為被上層的ICE函數(shù)調(diào)用，必須把ICE函數(shù)輸入?yún)?shù)從C數(shù)據(jù)類型轉(zhuǎn)化為mwArray類型并傳遞給DLL中的函數(shù)。本文設(shè)計了一組“mwArrayEx”的模板類，通過該模板類解決了輸入?yún)?shù)的數(shù)據(jù)類型轉(zhuǎn)化。示例如下：

template<>

classmwArrayEx//定義各種數(shù)據(jù)類型

{

public：

mwArrayEx(const string& data)

：m_Data(data)

{

}

～mwArrayEx(void)

{

}

operator mwArray()

{

return mwArray(m_Data.c_str())；

∥不同數(shù)據(jù)類型，獲取方式不同

}

private：

const string m_Data；

}；

相反，ICE函數(shù)的輸出參數(shù)則需要從mwArray類型轉(zhuǎn)化為C數(shù)據(jù)類型。本文通過設(shè)計定義一組名為“Dataconvert”的模板函數(shù)轉(zhuǎn)化Matlab矩陣數(shù)據(jù)為數(shù)組結(jié)構(gòu)來解決上述問題。由于原理類似，這里不做贅述。2種模板解決了Matlab程序與C++數(shù)據(jù)類型的相互轉(zhuǎn)化問題，使得函數(shù)能夠嚴(yán)格按照ICE規(guī)范實現(xiàn)服務(wù)的封裝。

依照以上設(shè)計原理，服務(wù)集成開發(fā)環(huán)境被設(shè)計為一個自動化的開發(fā)轉(zhuǎn)化工具，系統(tǒng)集成人員不需要了解具體算法，只需要應(yīng)用該工具轉(zhuǎn)化目標(biāo)文件(m文件或Cpp文件)為服務(wù)包，發(fā)布并部署于集群服務(wù)器，再通過服務(wù)管理軟件對服務(wù)流程組合編排就可以完成系統(tǒng)開發(fā)。開發(fā)環(huán)境的服務(wù)轉(zhuǎn)化流程如圖3所示。

圖3 服務(wù)開發(fā)環(huán)境服務(wù)轉(zhuǎn)化實現(xiàn)流程

具體步驟如下：

① 開發(fā)人員首先選擇需要轉(zhuǎn)化的目標(biāo)文件，可以是C++或Matlab語言。

② 軟件驗證目標(biāo)文件并根據(jù)函數(shù)定義及其注釋生成ICE接口文件[10]。同時，生成“mwArrayEx”和“Dataconvert”源文件，供類型轉(zhuǎn)化函數(shù)調(diào)用。

③ 軟件判斷需要轉(zhuǎn)化的源程序語言類型，如果是C++源程序直接通過ICE接口文件生成對應(yīng)的*I.h和*I.cpp、*ServerI.h和*IServer.cpp等服務(wù)源文件；如果是Matlab語言源程序需要通過調(diào)用mcc生成動態(tài)鏈接庫，并進(jìn)行數(shù)據(jù)類型轉(zhuǎn)化后再生成服務(wù)源程序。

④ 軟件生成XML格式的服務(wù)配置文件，主要包括：服務(wù)名稱、服務(wù)類型、配置參數(shù)、出入?yún)?shù)和輸出參數(shù)等信息。

⑤ 軟件生成整個服務(wù)工程文件(.sln)，自動調(diào)用VS2010編譯器對工程進(jìn)行編譯，生成服務(wù)包。

不難看出，本文設(shè)計開發(fā)的服務(wù)集成開發(fā)環(huán)境為用戶提供了自動化的服務(wù)開發(fā)能力。使得系統(tǒng)開發(fā)人員不需要了解具體算法設(shè)計及ICE開發(fā)規(guī)范就可以自動生成服務(wù)開發(fā)包(包括服務(wù)框架代碼、服務(wù)描述文件以及接口定義文件等)用以組合成業(yè)務(wù)系統(tǒng)。通過讓算法設(shè)計、組件開發(fā)和系統(tǒng)集成3個過程的相互分離，降低了服務(wù)開發(fā)及系統(tǒng)集成的難度。

2 分布式服務(wù)架構(gòu)設(shè)計及技術(shù)實現(xiàn)

2.1 架構(gòu)設(shè)計

當(dāng)前信號處理系統(tǒng)通常具有高吞吐率、大數(shù)據(jù)量的特點(diǎn)，從而要求系統(tǒng)具備高速的數(shù)據(jù)處理能力。現(xiàn)在很多基于通用硬件的軟件無線電平臺(如GNU Radio+USRP組合、微軟的SORA等)，由于基于組件模型設(shè)計思想，僅僅只有通過優(yōu)化CPU訪問來提高運(yùn)算效率，導(dǎo)致運(yùn)算能力始終有限[11]。為解決運(yùn)算性能瓶頸的問題，通過把各個計算任務(wù)分發(fā)到多個處理節(jié)點(diǎn)，充分利用計算機(jī)集群的計算機(jī)資源實現(xiàn)并行運(yùn)算，才是比較有效的解決方案。

本文服務(wù)架構(gòu)模型的基礎(chǔ)思想是就是讓業(yè)務(wù)組件以服務(wù)的形式存在于分布式系統(tǒng)中，服務(wù)間相對獨(dú)立、自包含、可重用，業(yè)務(wù)流程及系統(tǒng)功能由服務(wù)組裝和流程編排來實現(xiàn)[12]。為實現(xiàn)這種設(shè)計理念，本文的系統(tǒng)架構(gòu)可大致分為核心框架、注冊中心和應(yīng)用客戶端3個部分，如圖4所示。

圖4 架構(gòu)原理

核心框架扮演“服務(wù)提供者”角色，為請求者提供服務(wù)[11]。核心框架不僅作為服務(wù)部署的容器，還實現(xiàn)了服務(wù)管理、狀態(tài)監(jiān)控、流程編排與執(zhí)行、計算資源的負(fù)載均衡以及服務(wù)節(jié)點(diǎn)故障容錯等功能。

注冊中心采用ZooKeeper實現(xiàn)諸如統(tǒng)一命名服務(wù)、配置管理、分布式服務(wù)鎖以及集群管理等功能[12]。

應(yīng)用系統(tǒng)作為“服務(wù)請求者”，通過服務(wù)訪問模塊向注冊中心查詢服務(wù)信息，并調(diào)用服務(wù)框架中的相應(yīng)服務(wù)。

服務(wù)作為實現(xiàn)不同功能單元的自包容實體部署于核心框架中，通過服務(wù)組合的方式實現(xiàn)彼此的交互及數(shù)據(jù)交換，最終實現(xiàn)應(yīng)用系統(tǒng)的業(yè)務(wù)功能[13]。

2.2 負(fù)載均衡管理

為實現(xiàn)較高的資源利用率，本文采用前置負(fù)載計算的方式，在服務(wù)調(diào)用之前根據(jù)負(fù)載均衡策略，將任務(wù)請求轉(zhuǎn)發(fā)到具體的服務(wù)框架節(jié)點(diǎn)上[14]。

首先，服務(wù)節(jié)點(diǎn)會定時將服務(wù)的運(yùn)行信息(CPU占用率、線程數(shù)、服務(wù)調(diào)用次數(shù)、平均處理時間以及調(diào)用失敗次數(shù)等)上報到注冊中心的資源調(diào)度模塊上。資源調(diào)度模塊維護(hù)著一個負(fù)載信息表(LIT)，該表存放著服務(wù)器ID、服務(wù)器IP、當(dāng)前線程數(shù)Si、最大線程數(shù)max(Si)、負(fù)載參數(shù)Li、當(dāng)前負(fù)載LSi以及最大負(fù)載max(LSi)等信息。

資源調(diào)度模塊根據(jù)服務(wù)節(jié)點(diǎn)的運(yùn)行信息，假設(shè)有4項：C1，C2，C3，C4，負(fù)載參數(shù)各自的權(quán)值為Ki，其負(fù)載參數(shù)計算公式為：

(1)

系統(tǒng)實時取得各服務(wù)器中的服務(wù)調(diào)用線程數(shù)Si，各服務(wù)器根據(jù)此數(shù)據(jù)與此服務(wù)器最大能接受的請求線程數(shù)的比值Si/max(Si)作為各服務(wù)器負(fù)載的初始數(shù)據(jù)。由于服務(wù)類型的不同，每個服務(wù)占用的服務(wù)器資源也有差別，Li作為周期性從各服務(wù)器收集到的負(fù)載信息，被用作糾偏因子，用來糾正負(fù)載信息的誤差。集群中每個服務(wù)器最終負(fù)載計算公式為：

LSi=Si/max(Si)+KLi，

(2)

式中，K為Li的系數(shù)。

根據(jù)式(1)和式(2)計算出每個服務(wù)器最終的負(fù)載信息LSi，用LSi與服務(wù)器最大負(fù)載max(LSi)的比值來調(diào)整服務(wù)調(diào)用資源。采用服務(wù)調(diào)用平均時間最小為負(fù)載均衡策略，該比值越小，說明服務(wù)調(diào)用的平均時間越小，任務(wù)請求選擇最小耗時的服務(wù)節(jié)點(diǎn)進(jìn)行訪問，從而達(dá)到負(fù)載均衡的目的。

3 應(yīng)用實例及結(jié)果

為驗證框架的有效性，基于該框架設(shè)計實現(xiàn)了1個并行處理2個業(yè)務(wù)流程的信號處理系統(tǒng)。如圖5所示，其數(shù)據(jù)源是事先采集的數(shù)據(jù)文件，業(yè)務(wù)服務(wù)的處理結(jié)果通過通用數(shù)據(jù)處理服務(wù)推送給信號處理軟件進(jìn)行可視化界面展示。

圖5 基于服務(wù)框架的驗證應(yīng)用系統(tǒng)

通用數(shù)據(jù)處理服務(wù)是本框架提供的基礎(chǔ)服務(wù)(采用數(shù)據(jù)分發(fā)服務(wù)DDS實現(xiàn))，其功能是通過訂閱分發(fā)機(jī)制[15]，實現(xiàn)運(yùn)算結(jié)果向用戶界面、數(shù)據(jù)庫和文件系統(tǒng)的訂閱分發(fā)。該服務(wù)使得系統(tǒng)的界面顯示或存儲數(shù)據(jù)與數(shù)據(jù)處理業(yè)務(wù)服務(wù)解耦和[16]，從而保證系統(tǒng)的數(shù)據(jù)處理性能不受影響。

服務(wù)管理軟件能夠(如圖6所示)用可視化方式，把服務(wù)框架中已部署好的算法服務(wù)，按照實際業(yè)務(wù)流程連接組合起來，形成一組業(yè)務(wù)流程[17]。該軟件是管理服務(wù)框架的核心軟件，通過訪問注冊中心和服務(wù)容器可實現(xiàn)包括服務(wù)部署、注冊、組合和狀態(tài)監(jiān)控等綜合管理功能[18]。

圖6 服務(wù)管理軟件界面

在驗證系統(tǒng)中準(zhǔn)備了2臺服務(wù)器，以驗證分布式運(yùn)行環(huán)境下框架性能。采用大小為1 GB的采樣信號數(shù)據(jù)文件進(jìn)行測試，設(shè)置服務(wù)處理每包數(shù)據(jù)緩存為100 KB。組合并配置業(yè)務(wù)流程1輸出信號參數(shù)及頻譜數(shù)據(jù)，業(yè)務(wù)流程2輸出分析結(jié)果及星座圖。具體測試環(huán)境為CPU E5-263 0 v3 2.40 GHz 8C(×2)、內(nèi)存64 GB、操作系統(tǒng)Windows Server 2008 SP1，網(wǎng)絡(luò)帶寬100 MB/s。針對不同節(jié)點(diǎn)數(shù)(2個節(jié)點(diǎn)以上，等數(shù)量分別部署)，不同線程數(shù)量，對該系統(tǒng)進(jìn)行了性能測試，其測試結(jié)果如圖7所示。

圖7 算法性能測試結(jié)果

可以看出單一節(jié)點(diǎn)單一線程的應(yīng)用計算耗時較長，但在開啟多線程調(diào)用更多計算資源后[18]，運(yùn)算性能明顯提升。這說明該分布式運(yùn)行框架可通過擴(kuò)展硬件資源，有效提高運(yùn)行處理速度。

4 結(jié)束語

本文設(shè)計的分布式服務(wù)架構(gòu)是一種針對信號處理領(lǐng)域的開放式體系架構(gòu)，通過服務(wù)總線技術(shù)提高軟件的復(fù)用度、系統(tǒng)的擴(kuò)展性[19]。通過服務(wù)封裝使工程師可以快速搭建基于計算機(jī)集群軟件無線電系統(tǒng)，并通過分布式并行運(yùn)算來提高系統(tǒng)運(yùn)行效率[20]。實驗結(jié)果表明，框架滿足大數(shù)據(jù)應(yīng)用處理需求，有一定的應(yīng)用價值。