分布式實(shí)時(shí)系統(tǒng)面向方面的QoS監(jiān)控模型

摘要：分布式實(shí)時(shí)系統(tǒng)是一個(gè)非常重要且資源有限的系統(tǒng)，系統(tǒng)資源的調(diào)配策略很大程度上決定了系統(tǒng)是否能滿足實(shí)時(shí)性要求。要制定資源調(diào)配策略，首先要標(biāo)識(shí)出實(shí)時(shí)系統(tǒng)中的各種資源，建立起資源模型。面向方面是一種全新的編程思想，它和面向?qū)ο蠓椒ńY(jié)合解決了傳統(tǒng)軟件開發(fā)方法中的一些問題。文章結(jié)合面向方面技術(shù)，把QoS監(jiān)控作為一個(gè)關(guān)注點(diǎn)，通過UML的擴(kuò)展機(jī)制描述了分布式實(shí)時(shí)系統(tǒng)中資源模型的面向方面的QoS監(jiān)控模型。

關(guān)鍵詞：分布式實(shí)時(shí)系統(tǒng)；面向方面；資源管理；QoS監(jiān)控模型

0 引言

動(dòng)態(tài)分布式實(shí)時(shí)系統(tǒng)廣泛應(yīng)用在對響應(yīng)與處理時(shí)間有較高要求的系統(tǒng)，如汽車，飛機(jī)，核反應(yīng)堆等的控制，這些系統(tǒng)的故障輕則導(dǎo)致經(jīng)濟(jì)財(cái)產(chǎn)損失，重則對人類生命造成威脅。動(dòng)態(tài)分布式實(shí)時(shí)系統(tǒng)是一個(gè)資源有限的系統(tǒng)，能否確保系統(tǒng)的實(shí)時(shí)性，在很大程度上取決于系統(tǒng)資源的調(diào)配策略。制定資源調(diào)配策略，首先要標(biāo)識(shí)出實(shí)時(shí)系統(tǒng)中的各種資源，建立資源模型。在資源模型中，Qos(Quality of Service)對系統(tǒng)的行為進(jìn)行監(jiān)控，以保證系統(tǒng)在規(guī)定時(shí)間內(nèi)完成任務(wù)。所以QoS監(jiān)控對分布式實(shí)時(shí)系統(tǒng)來說是非常重要的。本文結(jié)合面向方面技術(shù)，利用UML的擴(kuò)展機(jī)制描述了分布式實(shí)時(shí)系統(tǒng)中資源模型的面向方面的QoS監(jiān)控模型。

1 面向方面

面向方面編程AOP(Aspect-Oriented Programming)是一種全新的編程思想，被認(rèn)為是一種影響二十一世紀(jì)人類生活，工作方式，及經(jīng)濟(jì)的技術(shù)思想。它將非功能需求形成的橫切關(guān)注點(diǎn)從功能需求形成的核心關(guān)注點(diǎn)中分離，從而可以將非功能需求與功能需求分別模塊化，單獨(dú)進(jìn)行設(shè)計(jì)與編碼，最后將兩者的代碼編織在一起形成最終的系統(tǒng)。面向方面編程(AOP)的思想與面向?qū)ο缶幊?OOP)的思想從思維方向上有很大的不同，它將系統(tǒng)開發(fā)時(shí)一維的思維方式轉(zhuǎn)變成二維的思維方式。利用面向方面編程(AOP)可以解決軟件開發(fā)過程中因代碼雜混、分散，導(dǎo)致軟件開發(fā)過程的可追蹤性差、開發(fā)效率低，特別是代碼的復(fù)用性不好、代碼質(zhì)量不高、軟件系統(tǒng)維護(hù)困難等一系列問題。文獻(xiàn)對UML在面向方面建模方法進(jìn)行了探討，通過引入時(shí)間方面來表達(dá)系統(tǒng)的時(shí)間特性，并對UML進(jìn)行相應(yīng)的擴(kuò)展來建立面向方面的實(shí)時(shí)系統(tǒng)模型。

2 資源模型

UML有兩個(gè)profile(剖面法)與實(shí)時(shí)系統(tǒng)建模有關(guān)，一個(gè)是“可調(diào)度性、性能和時(shí)間說明規(guī)范的UML^TMprofile”，另一個(gè)是“建模服務(wù)質(zhì)量和容錯(cuò)的特征及機(jī)制的UML^TMprofile”。第一個(gè)profile定義了實(shí)時(shí)系統(tǒng)通用資源模型，也定義了可調(diào)度性和性能分析模型。用UML描述實(shí)時(shí)系統(tǒng)其核心就是對Qos的描述。QoS信息直接或間接地代表了與模型相關(guān)的應(yīng)用系統(tǒng)的軟、硬件資源的物理屬性。第二個(gè)profile則定義了資源使用模型。實(shí)時(shí)系統(tǒng)的研究對象是系統(tǒng)資源。系統(tǒng)資源是指CPU、儲(chǔ)存空間、傳輸帶寬等軟硬件資源。在實(shí)踐中系統(tǒng)資源是有限的，而且大多數(shù)是共享的，當(dāng)一個(gè)資源需要同時(shí)處理多于一個(gè)的請求時(shí)，就要以一定的策略輪流響應(yīng)不同請求。在實(shí)時(shí)系統(tǒng)中，響應(yīng)時(shí)間的正確與否決定了系統(tǒng)的正確性；而能否在要求的時(shí)間內(nèi)作出響應(yīng)，很大程度上取決于系統(tǒng)資源的調(diào)配策略。要制定資源調(diào)配策略，首先就要標(biāo)志出實(shí)時(shí)系統(tǒng)中的各種資源。

核心資源模型定義了資源和QoS的本質(zhì)概念，這些概念也是實(shí)時(shí)資源模型的基礎(chǔ)；驅(qū)動(dòng)模型描述了實(shí)時(shí)系統(tǒng)實(shí)例行為間的因果關(guān)系；資源使用模型則體現(xiàn)了客戶(服務(wù)使用者)的概念，它描述客戶使用系統(tǒng)資源及其服務(wù)的模式；資源管理由資源、資源代理和資源管理器幾個(gè)不同的功能角色組成；資源類型描述了按不同標(biāo)準(zhǔn)劃分的資源分類；實(shí)現(xiàn)模型則描述了資源之間的關(guān)系。文獻(xiàn)介紹了如何定義QoS，管理QoS。

3 基于QoS的資源管理結(jié)構(gòu)

文獻(xiàn)6介紹了基于QoS的資源管理結(jié)構(gòu)。資源管理體系結(jié)構(gòu)(圖1)主要由5個(gè)子系統(tǒng)構(gòu)成：資源申請、QoS管理，資源調(diào)度、資源管理和資源配置管理。資源申請模塊在用戶提交任務(wù)后，為應(yīng)用創(chuàng)建一個(gè)資源集，負(fù)責(zé)本地或遠(yuǎn)程資源的申請；QoS管理模塊執(zhí)行層次轉(zhuǎn)換，把應(yīng)用Qos映射為系統(tǒng)QoS，根據(jù)資源的QoS協(xié)商結(jié)果，決定是否預(yù)留資源，在任務(wù)運(yùn)行時(shí)監(jiān)控任務(wù)資源的活動(dòng)情況和QoS變化，作出維持QoS、QoS降級(jí)和關(guān)閉服務(wù)的決定；資源調(diào)度模

塊根據(jù)資源預(yù)留情況，采用不同的調(diào)度策略來分配資源，控制資源管理模塊的執(zhí)行；資源管理模塊收集計(jì)算資源和網(wǎng)絡(luò)資源的使用率和可用率，并且控制資源訪問；資源配置模塊用于管理和分析硬件的配置信息，其中資源配置文件描述了計(jì)算資源和網(wǎng)絡(luò)資源的屬性和特征，其它模塊從它這里獲取所要的信息。

4 面向方面的QoS監(jiān)控模型

從以上所述，可以看出QoS監(jiān)控可以作為—個(gè)關(guān)注點(diǎn)橫切系統(tǒng)，以下就描述了分布式實(shí)時(shí)系統(tǒng)中資源模型的面向方面的QoS監(jiān)控模型。

QoS監(jiān)控主要是通過底層獲得正在進(jìn)行的Qos級(jí)別。QoS監(jiān)控在資源管理模塊中發(fā)揮著非常關(guān)鍵的作用，例如資源管理要根據(jù)QoS監(jiān)控提供的QoS參數(shù)決定是否對資源預(yù)留。此外，用戶對QoS的需求是變化的，且網(wǎng)絡(luò)上提供的資源也是動(dòng)態(tài)變化的(如帶寬的大小)，為了要保證應(yīng)用的QoS，用戶就要對系統(tǒng)的行為進(jìn)行必要的監(jiān)控。從監(jiān)控方法來看，不同的QoS參數(shù)反映了分布實(shí)時(shí)應(yīng)用的不同服務(wù)需求，難以采用統(tǒng)一的動(dòng)態(tài)監(jiān)測方法，所以對不同的應(yīng)用應(yīng)采用不同的監(jiān)控方法。下面我們看一個(gè)簡化的資源監(jiān)控模型——客戶請求監(jiān)控模塊設(shè)置任務(wù)的QoS。在這樣的場景中，考慮了三種不同的實(shí)體，用戶實(shí)體(Client)，監(jiān)控實(shí)體(QoSMonitor)，代理實(shí)體(QoSBroker)。圖2展示了本例UML類圖的簡化版本，圖中只示出了QoSMonitor和QoSBroker類。Client只關(guān)心自己任務(wù)Qos的變化，因此QoSBroker提供了startupOrder()這個(gè)帶參數(shù)的操作(沒有在類圖顯示)來描述操作的類型(維持QoS、QoS降級(jí)、關(guān)閉)、processid、要求資源QoS活動(dòng)條件。Client一般根據(jù)在給定的時(shí)間內(nèi)是否能完成任務(wù)來確定資源QoS活動(dòng)條件。當(dāng)監(jiān)測到不能完成任務(wù)時(shí)，就會(huì)觸發(fā)觸發(fā)警報(bào)，然后決定下一步的動(dòng)作，決定是調(diào)用degradation()方法(Qos降級(jí))還是調(diào)用closeQoS()方法(關(guān)閉Qos)。我們在QoSMonitor中就提供了一個(gè)設(shè)置警報(bào)的操作即setAlert()方法。為了實(shí)現(xiàn)容錯(cuò)，當(dāng)用戶調(diào)用了startupOrder()方法時(shí)，代理類將復(fù)制它的狀態(tài)。當(dāng)該操作完成之后，狀態(tài)又一次被復(fù)制。此外為了能保持被通知有關(guān)QoSMonitor所實(shí)施的操作細(xì)節(jié)，在QoSBroker中提供了confirm()這個(gè)方法。

圖3為該示例的一個(gè)時(shí)序圖。setAlert()和alarmTrigger()都僅僅用于協(xié)調(diào)，它橫切了QoSBroker和QoSMonitor類，而duplicate()方法只是用于復(fù)制，它橫切了QoSBroker類的不同示例。如果用面向?qū)ο蠓椒▉硖幚磉@些屬性。會(huì)導(dǎo)致代碼分散在許多組件中，這樣就造成了代碼分散。而且一個(gè)基于Java或者其它語言的實(shí)現(xiàn)將導(dǎo)致不同實(shí)體的集合(對象，組件或者其它)有相同的接口。在各個(gè)組件中，業(yè)務(wù)邏輯代碼和系統(tǒng)日志、安全、同步等代碼交織在一起，將導(dǎo)致代碼交織。這種解決方案不但妨礙了對于單獨(dú)關(guān)注點(diǎn)的處理，而且將影響很多系統(tǒng)性能，如可維護(hù)性和可重用性等。

我們采用AOP方法時(shí)就可以把協(xié)調(diào)和復(fù)制問題分離成不同的關(guān)注點(diǎn)即不同的方面，然后橫切到系統(tǒng)中，如圖4所示。這樣，在QoSBroker和QoSMonitor類中，我們只關(guān)注于那些功能性問題，而協(xié)調(diào)和復(fù)制這兩個(gè)方面現(xiàn)在被封裝在兩個(gè)不同的實(shí)體之中。在每個(gè)方面中定義了不同的切入點(diǎn)，每個(gè)切入點(diǎn)定義了一組位置，方面代碼將被植入其中。例如，PC_dupli切入點(diǎn)描述了在方法starmpOrder()和confirm()方法執(zhí)行之后，方法duplicate()必須被執(zhí)行。這種AOP方法簡化了對系統(tǒng)行為中形成的不同關(guān)注點(diǎn)的判斷。協(xié)調(diào)或者復(fù)制的改變不影響到其他模塊，這樣就被很好的局部化了，提高了可維護(hù)性。此外它還提高了不同方面的代碼的可重用性和適配性。

5 結(jié)束語

分布式實(shí)時(shí)系統(tǒng)是一個(gè)正處于發(fā)展期的系統(tǒng)，許多方面還有待進(jìn)一步研究和完善。資源管理是分布式實(shí)時(shí)系統(tǒng)一個(gè)很重要的組成部分。本文采用AOP方法，給出了分布式實(shí)時(shí)系統(tǒng)資源管理的面向方面QoS監(jiān)控模型，很好地解決了開發(fā)過程中的代碼雜混、分散等問題。