一種支持私有云仿真的HLA/RTI實(shí)現(xiàn)方法

黃繼杰，林昌年，楊選懷，王蘭香，王國(guó)平

(北京科東電力控制系統(tǒng)有限責(zé)任公司，北京 100192)

0 引 言

分布式仿真標(biāo)準(zhǔn)IEEE1516基于面向?qū)ο蠹夹g(shù)提出了高層體系架構(gòu)(HLA)。為了適應(yīng)面向服務(wù)的仿真環(huán)境，IEEE1516-2010版對(duì)HLA進(jìn)行了許多擴(kuò)展[1-2]，并采用WSPRC組件(Web services provider RTI component)技術(shù)使HLA/RTI能支持Web環(huán)境下的仿真[3-4]。云計(jì)算技術(shù)的蓬勃發(fā)展使仿真資源得到更高層次的共享，因而“云仿真”將是未來(lái)分布仿真的主要研究方向[5-6]。文獻(xiàn)[7]研究了云仿真技術(shù)與HLA Evolved技術(shù)進(jìn)行綜合的問(wèn)題，采用的技術(shù)手段還是對(duì)HLA進(jìn)行擴(kuò)展。

隨著虛擬化技術(shù)的快速發(fā)展，出現(xiàn)了虛擬化容器技術(shù)(如Docker[8-9])，并且使基于單體式軟件架構(gòu)的SaaS層云服務(wù)可拆分為許多微服務(wù)[10]?；贒ocker和微服務(wù)來(lái)部署私有云[11]就可采用一臺(tái)高性能的服務(wù)器，根據(jù)仿真任務(wù)的需要啟動(dòng)Docker容器，并將仿真模型微服務(wù)部署其中[12]。這種虛擬化和微服務(wù)技術(shù)使得HLA與面向服務(wù)技術(shù)能更好地結(jié)合。

HLA的對(duì)象模板類(OMT)是其支持聯(lián)邦成員交互的基礎(chǔ)。文中先利用OMT的對(duì)象屬性來(lái)定義仿真模型微服務(wù)的特殊標(biāo)志及相關(guān)信息，并在RTI實(shí)現(xiàn)中，當(dāng)遇到對(duì)象屬性名為仿真模型微服務(wù)的特殊標(biāo)志時(shí)，由RTI來(lái)負(fù)責(zé)完成對(duì)模型微服務(wù)的訪問(wèn)。

1 私有仿真云中部署微服務(wù)

隨著虛擬化容器技術(shù)的興起，產(chǎn)生了微服務(wù)，比如現(xiàn)在非常通用的Docker容器。Docker與虛擬機(jī)不同，Docker容器并不是一套硬件虛擬化方案，而是一個(gè)操作系統(tǒng)級(jí)別的虛擬化技術(shù)，僅為應(yīng)用提供一套隔離的運(yùn)行時(shí)虛擬環(huán)境，而不是整個(gè)虛擬的硬件資源。Docker是以容器為資源分割和調(diào)度的基本單元和調(diào)度單位，封裝了整個(gè)服務(wù)運(yùn)行時(shí)的環(huán)境，用于構(gòu)建、發(fā)布和運(yùn)行分布式應(yīng)用的平臺(tái)。它使用Linux內(nèi)核提供的LXC技術(shù)實(shí)現(xiàn)類似虛擬機(jī)的功能，以更節(jié)省的方式利用硬件資源，提供用戶更多更高效的計(jì)算資源服務(wù)。

在Docker內(nèi)部署的微服務(wù)改變了軟件架構(gòu)模式，使軟件架構(gòu)從單體式轉(zhuǎn)向了微服務(wù)的架構(gòu)模式。單體式軟件架構(gòu)也稱為集中式軟件體系架構(gòu)，是指所有的功能在一個(gè)應(yīng)用中，各個(gè)模塊之間通過(guò)相互調(diào)用的方式交互。單體式軟件架構(gòu)具有以下不足：維護(hù)和擴(kuò)展困難；難于持續(xù)部署；應(yīng)用伸縮性差和可靠性低。因此，在云平臺(tái)中這種單體式架構(gòu)如今正開(kāi)始被最新的微服務(wù)架構(gòu)逐漸取代。

微服務(wù)軟件架構(gòu)被定義為：“開(kāi)發(fā)單個(gè)服務(wù)組件作為一系列應(yīng)用的套件，其中每個(gè)服務(wù)可以使用不同的編程語(yǔ)言實(shí)現(xiàn)，以及不同的存儲(chǔ)技術(shù)獨(dú)立運(yùn)行在自己的進(jìn)程空間中，圍繞著業(yè)務(wù)功能而構(gòu)建，可通過(guò)完全獨(dú)立的自動(dòng)化部署機(jī)制進(jìn)行構(gòu)建和部署，實(shí)現(xiàn)去中心化服務(wù)、集中式管理最小化，各個(gè)服務(wù)之間通過(guò)輕量級(jí)機(jī)制實(shí)現(xiàn)通信”。微服務(wù)具有以下特點(diǎn)：彼此獨(dú)立；原子化；組合和重構(gòu)?；谖⒎?wù)開(kāi)發(fā)的系統(tǒng)其所有的個(gè)體由于在概念上是對(duì)等的，結(jié)構(gòu)相對(duì)模塊化、簡(jiǎn)單化，因此具有松散耦合的特點(diǎn)，構(gòu)成的系統(tǒng)具有更強(qiáng)的可擴(kuò)展性和魯棒性。

2 OMT支持微服務(wù)的策略

HLA基于OMT來(lái)實(shí)現(xiàn)聯(lián)邦成員間的數(shù)據(jù)交互，其中對(duì)象屬性更新是最常用的方式。而對(duì)象屬性的計(jì)算常常通過(guò)調(diào)用模型的接口來(lái)獲得。由于微服務(wù)軟件架構(gòu)相比單體架構(gòu)具有優(yōu)勢(shì)，用于計(jì)算對(duì)象屬性的模型接口越來(lái)越多地采用微服務(wù)的接口。在私有云內(nèi)的微服務(wù)環(huán)境下進(jìn)行分布交互仿真一般采用圖1左側(cè)的方式，即聯(lián)邦成員先調(diào)用私有云內(nèi)的模型微服務(wù)計(jì)算對(duì)象屬性，再將對(duì)象屬性的更新值通過(guò)私有云內(nèi)的RTI服務(wù)發(fā)布到其他聯(lián)邦成員。

圖1 RTI支持微服務(wù)的通信架構(gòu)

當(dāng)設(shè)計(jì)FOM/SOM時(shí)，將聯(lián)邦成員計(jì)算對(duì)象屬性的輸入?yún)?shù)和輸出參數(shù)加入到OMT中，以此代替該原對(duì)象需要更新的屬性，其發(fā)布過(guò)程如圖1右所示[13]。由于模型服務(wù)和RTI服務(wù)都位于私有云服務(wù)器，而服務(wù)器內(nèi)部進(jìn)程間的通信速度高于局域網(wǎng)中機(jī)器間的進(jìn)程通信速度，故圖1右所示的數(shù)據(jù)交互速度比左圖所表示的更快。

設(shè)計(jì)OMT時(shí)可以像文獻(xiàn)[14]一樣，在OMT具體的FED文件中增加關(guān)鍵詞來(lái)標(biāo)示此對(duì)象需要RTI訪問(wèn)的微服務(wù)?？紤]到與IEEE1516現(xiàn)有標(biāo)準(zhǔn)的一致性，利用對(duì)象類名加“_microService”字段來(lái)通知RTI，由它先調(diào)用微服務(wù)更新對(duì)象屬性，再查閱訂購(gòu)者并將更新值發(fā)給它。以學(xué)生對(duì)象類(Class Student)為例[15]，假設(shè)它包含三個(gè)屬性(LunchMoney，AmmoAmount和Cleanliness)，并通過(guò)CalculateStudent函數(shù)來(lái)重新計(jì)算(LunchMoney，AmmoAmount和Cleanliness )這三個(gè)屬性?，F(xiàn)將CalculateStudent函數(shù)封裝為微服務(wù)的接口，接口參數(shù)包括代表這三個(gè)屬性的輸入和輸出，此外還包括微服務(wù)的地址。為此，將學(xué)生類對(duì)象(新類名為Student_microService)重定義為七個(gè)屬性(addr_CalculateStudent，in_LunchMoney，in_AmmoAmount，in_Cleanliness，out_LunchMoney，out_AmmoAmount，out_Cleanliness)。RTI在調(diào)完微服務(wù)后將原來(lái)數(shù)據(jù)分發(fā)的處理量由(LunchMoney，AmmoAmount和Cleanliness )轉(zhuǎn)向其中的(out_LunchMoney，out_AmmoAmount和out_Cleanliness)這三個(gè)屬性，并可用這三個(gè)輸出屬性過(guò)濾基于HLA的區(qū)域。OMT中命名統(tǒng)一規(guī)定為：前綴“addr_”表示接口地址，“in_”表示輸入?yún)?shù)屬性，“out_”表示輸出參數(shù)屬性。

3 支持微服務(wù)的RTI實(shí)現(xiàn)方法

在開(kāi)源CERTI源碼的基礎(chǔ)上進(jìn)行RTI服務(wù)端的修改[16]，涉及到對(duì)象聲明管理和對(duì)象管理兩部分。RTI服務(wù)端在處理對(duì)象聲明管理時(shí)，需要嵌入對(duì)類名稱的判斷，若類名字后部包含“_microService”，則該對(duì)象類的實(shí)例需要由RTI服務(wù)端調(diào)用微服務(wù)來(lái)計(jì)算各對(duì)象的屬性并完成發(fā)布和訂閱功能。處理流程如圖2所示。

圖2 RTI支持微服務(wù)的處理流程

圖2中，當(dāng)判斷為“否”時(shí)，程序流程走的是原RTI服務(wù)處理流程；當(dāng)判斷為“是”時(shí)，先設(shè)置需調(diào)用微服務(wù)接口的標(biāo)志，然后查看屬性名的前綴是否包含“in_”和“out_”，若包含“in_”為該屬性的輸入?yún)?shù)，若包含“out_”為該屬性的輸出參數(shù)。對(duì)微服務(wù)接口地址參數(shù)，通過(guò)查看是否包含前綴“addr_”來(lái)獲得，如學(xué)生對(duì)象類所調(diào)的微服務(wù)接口，其屬性為：“addr_CalculateStudent”。

在后面的學(xué)生對(duì)象更新其屬性時(shí)，屬性“addr_CalculateStudent”所對(duì)應(yīng)的值由微服務(wù)的配置文件和此接口的名構(gòu)成，如“exchange.inf@startPower Exchange”，其中exchange.inf是配置文件，startPowerExchange是接口名。

RTI實(shí)現(xiàn)中將屬性映射為屬性句柄，通過(guò)(句柄值和屬性值)來(lái)打包傳輸數(shù)據(jù)；對(duì)于接口的參數(shù)名也需要與屬性的句柄值相關(guān)聯(lián)。為此，輸入?yún)?shù)屬性在RTI解析FOM/SOM時(shí)會(huì)將屬性名映射為屬性句柄，且RTI在分配屬性句柄時(shí)是按自動(dòng)遞增順序來(lái)計(jì)算句柄值的。故按微服務(wù)接口參數(shù)的順序依次定義FOM/SOM中的訪問(wèn)該微服務(wù)的對(duì)象類的屬性，則參數(shù)值、屬性句柄值和屬性值是一一對(duì)應(yīng)的關(guān)系。RTI在調(diào)用該接口時(shí)，先獲得該接口的全部參數(shù)，并按對(duì)應(yīng)的屬性句柄大小進(jìn)行屬性值排隊(duì)，從而按此順序?qū)傩灾底鳛閰?shù)來(lái)調(diào)用對(duì)應(yīng)的微服務(wù)接口。

同樣，對(duì)于輸出參數(shù)屬性，同樣需要此微服務(wù)接口在計(jì)算完后按輸入?yún)?shù)的順序進(jìn)行數(shù)據(jù)打包。包格式為：4字節(jié)參數(shù)個(gè)數(shù)，第一個(gè)參數(shù)字節(jié)長(zhǎng)度，第一個(gè)參數(shù)內(nèi)容，第二個(gè)參數(shù)長(zhǎng)度，第二個(gè)參數(shù)內(nèi)容，以此類推。當(dāng)RTI服務(wù)端調(diào)用此微服務(wù)接口后，對(duì)獲得的返回值進(jìn)行上述格式的解包，并按輸出參數(shù)屬性句柄的大小依次賦值給各輸出參數(shù)屬性。

由于只有輸出參數(shù)屬性是需要在聯(lián)邦間交互的值，故對(duì)于對(duì)象類的訂購(gòu)處理流程按CERTI的原代碼處理，包括數(shù)據(jù)分發(fā)的區(qū)域過(guò)濾也按CERTI的原代碼處理。

4 RTI對(duì)多租戶微服務(wù)的訪問(wèn)

當(dāng)私有云中的微服務(wù)支持同一用戶多次訪問(wèn)時(shí)，微服務(wù)可采用SaaS的多租戶技術(shù)。多租戶技術(shù)的實(shí)現(xiàn)重點(diǎn)在于不同租戶間應(yīng)用程序環(huán)境的隔離(application context isolation)以及數(shù)據(jù)的隔離(data isolation)，以維持不同租戶間應(yīng)用程序不會(huì)相互干擾，同時(shí)數(shù)據(jù)的保密性也夠強(qiáng)。

與訪問(wèn)微服務(wù)的租戶所對(duì)應(yīng)的是RTI中的聯(lián)邦執(zhí)行號(hào)、聯(lián)邦成員號(hào)和對(duì)象實(shí)例句柄號(hào)[17]。當(dāng)RTI服務(wù)重啟后，RTI服務(wù)端對(duì)聯(lián)邦執(zhí)行號(hào)、聯(lián)邦成員號(hào)和對(duì)象實(shí)例句柄號(hào)的賦值又會(huì)從1開(kāi)始遞增編號(hào)，故與微服務(wù)所用的租戶號(hào)不能一一對(duì)應(yīng)。但聯(lián)邦執(zhí)行的名字是唯一的，用戶可多次運(yùn)行此名字的聯(lián)邦執(zhí)行。用戶每次創(chuàng)建該聯(lián)邦執(zhí)行，表示其要進(jìn)行一次仿真實(shí)驗(yàn)，用實(shí)驗(yàn)次數(shù)與聯(lián)邦執(zhí)行的名字來(lái)唯一確定數(shù)據(jù)表中的一條記錄。對(duì)于此次實(shí)驗(yàn)中的每一對(duì)象實(shí)例，用其實(shí)例句柄與上述記錄號(hào)而得的二元信息，可唯一標(biāo)識(shí)對(duì)象實(shí)例對(duì)微服務(wù)的訪問(wèn)，也即與租戶號(hào)相對(duì)應(yīng)了。所以可用三元組[聯(lián)邦執(zhí)行的名字，實(shí)驗(yàn)次數(shù)號(hào)，對(duì)象實(shí)例句柄號(hào)]來(lái)查詢租戶表中所對(duì)應(yīng)的租戶號(hào)。

為此，RTI服務(wù)端在啟動(dòng)時(shí)需要連接上數(shù)據(jù)庫(kù)，在創(chuàng)建聯(lián)邦時(shí)以聯(lián)邦執(zhí)行的名字為索引到庫(kù)表中查找記錄，獲得最大的聯(lián)邦執(zhí)行實(shí)驗(yàn)次數(shù)號(hào)，并加1作為新記錄寫入庫(kù)表中，同時(shí)返回并得該記錄的記錄號(hào)FID。當(dāng)創(chuàng)建對(duì)象實(shí)例時(shí)，將記錄號(hào)FID和該實(shí)例的句柄號(hào)及實(shí)例名一起寫入另一庫(kù)表，同時(shí)返回并得該記錄的記錄號(hào)TID，也即是租戶ID。

5 私有云中構(gòu)建基于RTI擴(kuò)展的實(shí)驗(yàn)

在構(gòu)建跨國(guó)和跨洲的全球能源互聯(lián)網(wǎng)云仿真實(shí)驗(yàn)中采用文中擴(kuò)展的RTI功能[18]。全球能源互聯(lián)網(wǎng)由跨洲、跨國(guó)骨干網(wǎng)架和各國(guó)各電壓等級(jí)電網(wǎng)(輸電網(wǎng)、配電網(wǎng))構(gòu)成，具體的硬件結(jié)構(gòu)如圖3所示。

圖3 全球能源互聯(lián)網(wǎng)電力交易圖

為了保證系統(tǒng)實(shí)時(shí)運(yùn)行時(shí)的電力平衡，需要進(jìn)行實(shí)時(shí)平衡市場(chǎng)的交易。在實(shí)時(shí)平衡市場(chǎng)中，需求側(cè)和供給側(cè)交易主體根據(jù)自身交易需求情況，向所在轄區(qū)國(guó)的系統(tǒng)運(yùn)營(yíng)機(jī)構(gòu)提交競(jìng)標(biāo)的價(jià)格和數(shù)量，系統(tǒng)運(yùn)營(yíng)機(jī)構(gòu)把每小時(shí)的報(bào)價(jià)按照價(jià)格排序，然后根據(jù)交易需求對(duì)每小時(shí)的系統(tǒng)進(jìn)行匹配。在對(duì)各國(guó)進(jìn)行電力交易仿真時(shí)，需要根據(jù)電網(wǎng)內(nèi)所有負(fù)荷和所有發(fā)電機(jī)組的出力及其報(bào)價(jià)，以電網(wǎng)內(nèi)所有用戶購(gòu)電費(fèi)用最小為最優(yōu)化目標(biāo)，通過(guò)線性規(guī)劃算法，最終給出每個(gè)發(fā)電廠的發(fā)電量和上網(wǎng)報(bào)價(jià)。

此實(shí)驗(yàn)采用微服務(wù)的設(shè)計(jì)架構(gòu)，為此需要構(gòu)建電力交易微服務(wù)。該服務(wù)需要設(shè)置每個(gè)節(jié)點(diǎn)的負(fù)荷L，機(jī)組個(gè)數(shù)Ng及報(bào)價(jià)Pg和容量Cg，支路(i,j)電抗Xij，最大傳輸有功功率PMij。設(shè)決策變量機(jī)組g實(shí)際出力為Ug，其線性規(guī)劃模型為：

最優(yōu)目標(biāo)函數(shù)是購(gòu)電費(fèi)用最小：

(1)

約束條件包括：

能量平衡約束：

(2)

機(jī)組容量約束：

0≤Ug≤Cg,g=1,2,…,NG

(3)

支路容量約束：

(4)

其中支路容量約束又需要通過(guò)計(jì)算網(wǎng)絡(luò)直流潮流的微服務(wù)來(lái)獲得，電網(wǎng)直流潮流微服務(wù)計(jì)算在發(fā)電模塊產(chǎn)生的能量(功率)、負(fù)荷模塊消耗的能量(功率)及各條線路的電抗已知的情況下，可以計(jì)算節(jié)點(diǎn)模型間能量的流動(dòng)。

(5)

其中，θi和θj分別為線路兩端的直流電位；Xij(或電納為Bij)是線路的直流電阻。

(6)

用矩陣形式表示為：

[B0][θ]=[P]

(7)

其中，B0為正常運(yùn)行時(shí)的網(wǎng)絡(luò)節(jié)點(diǎn)電納矩陣；θ為節(jié)點(diǎn)電壓相位角的向量；P為節(jié)點(diǎn)注入的有功功率向量。當(dāng)B0和P已知時(shí)，用上式可以容易地求得各節(jié)點(diǎn)電壓相位角，進(jìn)一步可算出各支路的有功功率潮流。

電力交易微服務(wù)[19]和直流潮流計(jì)算微服務(wù)基于ZeroC公司的ICE實(shí)現(xiàn)。RTI服務(wù)端組件在啟動(dòng)時(shí)連接MySql數(shù)據(jù)庫(kù)，在對(duì)象實(shí)例訪問(wèn)微服務(wù)時(shí)，創(chuàng)建ICE的連接，如下：

Ice::CommunicatorHolder

ich(argcEnv,argvEnv,"exchange.inf");

auto twoway=Ice::checkedCast(communicator->propertyToProxy("Exchang.Proxy")->ice_twoway()->ice_secure(false));

UgStr=twoway->startPowerExchange(L，NG，Pg，Cg，Xij，PMij，TenantID);

由于電力交易微服務(wù)需要獲得參與仿真的各國(guó)的輸入?yún)?shù)，包括線路阻抗和最大容量，電力網(wǎng)絡(luò)各節(jié)點(diǎn)的申報(bào)負(fù)荷量和申報(bào)報(bào)價(jià)，各節(jié)點(diǎn)機(jī)組的申報(bào)發(fā)電量和申報(bào)價(jià)格，而后才能計(jì)算。所以各國(guó)需要在兩個(gè)仿真步長(zhǎng)內(nèi)調(diào)用兩次交易對(duì)象的屬性更新接口。在第一步長(zhǎng)內(nèi)，將參數(shù)送電力交易微服務(wù)，由微服務(wù)將參數(shù)值寫入庫(kù)表，并將返回各國(guó)對(duì)象實(shí)例的參數(shù)置為空；在第二步長(zhǎng)內(nèi)，各國(guó)交易對(duì)象實(shí)例更新參數(shù)時(shí)，電力交易微服務(wù)通過(guò)查庫(kù)表可知該值已存在，則表明前面第一次的參數(shù)已全部獲得，故啟動(dòng)最優(yōu)化計(jì)算，并將計(jì)算結(jié)果寫入數(shù)據(jù)庫(kù)表中。

RTI服務(wù)端組件調(diào)用電力交易微服務(wù)接口，該接口直接從數(shù)據(jù)庫(kù)中讀出該對(duì)象的信息并返回，RTI服務(wù)端組件通過(guò)解析返回的數(shù)據(jù)流，獲得對(duì)象實(shí)例的實(shí)際出力Ug和最優(yōu)報(bào)價(jià)Pg并發(fā)布到各國(guó)。發(fā)出更新請(qǐng)求的對(duì)象實(shí)例也將收到自己的最優(yōu)報(bào)價(jià)和最優(yōu)發(fā)電量。而之前對(duì)象實(shí)例更新的輸入?yún)?shù)是各國(guó)期望的價(jià)格和發(fā)電量，還不能保證實(shí)時(shí)運(yùn)行時(shí)的電力平衡，只有RTI服務(wù)端組件通過(guò)調(diào)用微服務(wù)而得到的最優(yōu)報(bào)價(jià)和最優(yōu)發(fā)電量才能滿足實(shí)時(shí)運(yùn)行時(shí)的電力平衡。

6 結(jié)束語(yǔ)

RTI的服務(wù)端組件可與微服務(wù)共同部署到私有云服務(wù)器上，使得聯(lián)邦成員在更新對(duì)象實(shí)例前訪問(wèn)私有云中計(jì)算微服務(wù)的方式，轉(zhuǎn)變?yōu)橛蒖TI服務(wù)端來(lái)訪問(wèn)云中的微服務(wù)，減少了數(shù)據(jù)在局域網(wǎng)內(nèi)的傳輸次數(shù)。RTI服務(wù)端組件通過(guò)與數(shù)據(jù)庫(kù)相連，將聯(lián)邦執(zhí)行名、實(shí)驗(yàn)次數(shù)和對(duì)象實(shí)例與微服務(wù)的租戶號(hào)相對(duì)應(yīng)，使RTI能調(diào)用微服務(wù)計(jì)算出對(duì)象實(shí)例的屬性更新值并發(fā)布出去，從而拓展了RTI與模型服務(wù)的結(jié)合方式。文中利用IEEE1516的OMT來(lái)定義對(duì)象類屬性與微服務(wù)接口參數(shù)的對(duì)應(yīng)關(guān)系，若在OMT中直接定義與微服務(wù)接口相關(guān)的信息會(huì)使HLA與服務(wù)化更深度融合，這將是IEEE1516繼續(xù)發(fā)展的一個(gè)方向。