黃繼杰，林昌年，楊選懷，王蘭香，王國平

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

0 引 言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最優(yōu)目標(biāo)函數(shù)是購電費(fèi)用最?。?/p>

(1)

約束條件包括：

能量平衡約束：

(2)

機(jī)組容量約束：

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

(3)

支路容量約束：

(4)

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

(5)

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

(6)

用矩陣形式表示為：

[B0][θ]=[P]

(7)

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

電力交易微服務(wù)[19]和直流潮流計算微服務(wù)基于ZeroC公司的ICE實現(xiàn)。RTI服務(wù)端組件在啟動時連接MySql數(shù)據(jù)庫，在對象實例訪問微服務(wù)時，創(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ù)需要獲得參與仿真的各國的輸入?yún)?shù)，包括線路阻抗和最大容量，電力網(wǎng)絡(luò)各節(jié)點(diǎn)的申報負(fù)荷量和申報報價，各節(jié)點(diǎn)機(jī)組的申報發(fā)電量和申報價格，而后才能計算。所以各國需要在兩個仿真步長內(nèi)調(diào)用兩次交易對象的屬性更新接口。在第一步長內(nèi)，將參數(shù)送電力交易微服務(wù)，由微服務(wù)將參數(shù)值寫入庫表，并將返回各國對象實例的參數(shù)置為空；在第二步長內(nèi)，各國交易對象實例更新參數(shù)時，電力交易微服務(wù)通過查庫表可知該值已存在，則表明前面第一次的參數(shù)已全部獲得，故啟動最優(yōu)化計算，并將計算結(jié)果寫入數(shù)據(jù)庫表中。

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

6 結(jié)束語

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