1.引言

2? 基于JMX 管理架構(gòu)進(jìn)行設(shè)計的可行性?

??? JMX （Java Management Extension）是Sun和其它一些致力于管理軟件開發(fā)的公司共同推出的Java管理體系框架，它描述了可擴(kuò)展的體系結(jié)構(gòu)、API 和一組使用 Java 編程語言用于網(wǎng)絡(luò)管理的分布式服務(wù)，用可管理性方面的特性擴(kuò)展了 Java 平臺。在 JMX 體系結(jié)構(gòu)中，采用三級分而治之的體系結(jié)構(gòu)化方法來降低可伸縮網(wǎng)絡(luò)管理的復(fù)雜性，各層對象可獨立于其它層對象來進(jìn)行開發(fā)。它們是：?

工具層：在本層，可管理端點（設(shè)備、軟件服務(wù)等）可通過 JMX 指定的接口訪問。通過提供 Java MBean 封裝器，可以輕松地將舊的非 JMX 設(shè)備和服務(wù)“調(diào)整”成 JMX 可管理的資源。?

代理層：在本層中，公開了 JMX 代理的內(nèi)部體系結(jié)構(gòu)。JMX 代理是軟件組件，它向遠(yuǎn)程管理組件公開一組標(biāo)準(zhǔn)化代理服務(wù)并通過 JMX 可管理資源的 MBean 接口直接控制這些資源。代理通過連接器或協(xié)議適配器與管理應(yīng)用程序通信。?

分布式服務(wù)層：在本層中，目標(biāo)是指定為JMX Manager組件提供的接口。JMX Manager 可以訪問代理或代理組來管理由代理公開的JMX可管理的資源。

??? 體系結(jié)構(gòu)如圖1所示：?

??? 因此，JMX允許網(wǎng)絡(luò)管理系統(tǒng)(NMS)、企業(yè)管理系統(tǒng)(EMS) 和其它管理／控制應(yīng)用程序管理基于 Java 平臺的軟件應(yīng)用程序、服務(wù)和設(shè)備。JMX管理架構(gòu)利用了當(dāng)今最新的軟件體系結(jié)構(gòu)設(shè)計中的最佳實踐，并以較低的實現(xiàn)成本提供了分布式的、兼容的、可擴(kuò)展的和健壯的 Java 軟件可管理性的解決方案。

3? 網(wǎng)絡(luò)性能管理系統(tǒng)的體系結(jié)構(gòu)?

??? 在高速IP網(wǎng)絡(luò)環(huán)境中，要使系統(tǒng)能高效的處理海量級數(shù)據(jù)的采集、處理與存儲，并且要具有延時少的特性，必須有效的分離數(shù)據(jù)顯示、數(shù)據(jù)處理與數(shù)據(jù)存儲的功能。作為系統(tǒng)核心部分的JMX服務(wù)器實現(xiàn)數(shù)據(jù)的處理功能，它由數(shù)據(jù)采集、數(shù)據(jù)分析、數(shù)據(jù)存取、告警控制、接口這五個模塊組成，將這些重要的處理功能封裝在Mbean中，并在JMX服務(wù)器上注冊，供客戶端的應(yīng)用程序遠(yuǎn)程調(diào)用。JMX服務(wù)器將處理后的數(shù)據(jù)按照一定策略保存到數(shù)據(jù)庫服務(wù)器中，數(shù)據(jù)庫服務(wù)器采用Sybase數(shù)據(jù)庫技術(shù)，它能對其中海量數(shù)據(jù)進(jìn)行快速入庫與查詢，為JMX服務(wù)器提供可靠的數(shù)據(jù)支持?？蛻舳藨?yīng)用程序運行在客戶機(jī)上，為網(wǎng)絡(luò)管理人員提供圖形界面，將從服務(wù)器上獲取的數(shù)據(jù)反映在管理界面中，并可獲取管理人員的指令，獲取JMX服務(wù)器上的服務(wù)。網(wǎng)絡(luò)性能監(jiān)測系統(tǒng)的結(jié)構(gòu)圖如圖2：?

??? 系統(tǒng)充分利用JAVA分布式、健壯、安全、體系結(jié)構(gòu)中立、可移植、高性能、多線程和動態(tài)等特點，實現(xiàn)系統(tǒng)與硬件和操作系統(tǒng)的平臺無關(guān)性，方便進(jìn)行系統(tǒng)分布和移植擴(kuò)展。通過利用JMX提供的系統(tǒng)管理服務(wù)，在開發(fā)過程中可以簡化模塊之間集成和通信等管理工作，使系統(tǒng)的各個部分以松耦合方式集成在一起，為以后的進(jìn)一步開發(fā)和各部分功能的按需發(fā)布打下良好基礎(chǔ)。在JMX Agent與客戶的通信中，使用了RMI Connector，它解決了系統(tǒng)底層的網(wǎng)絡(luò)通信問題，使系統(tǒng)可以方便的運行在多個JVM虛擬機(jī)中。

4? 設(shè)計模式對系統(tǒng)設(shè)計的優(yōu)化?

??? 設(shè)計模式第一次是由架構(gòu)設(shè)計師 Christopher Alexander 在他所著的 A Pattern Language: Towns, Buildings, Construction（Oxford University Press，1977）一書中提到的。他引入了這一概念，并稱為模式 — 對于反復(fù)出現(xiàn)設(shè)計問題的抽象解決方案，這一概念吸引了其它領(lǐng)域中一些研究人員的注意，其中最有影響的書籍：Design Patterns: Elements of Reusable Object-Oriented Software，由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 合著，幾位作者常被稱為“四人組（Gang of Four）”，而這本書也就被稱為“四人組（或 GoF）”書?！八娜私M”將模式描述為“在一定的環(huán)境中解決某一問題的方案”。在設(shè)計面向?qū)ο蟮能浖?，關(guān)鍵步驟是發(fā)現(xiàn)對象。缺少經(jīng)驗或指導(dǎo)會導(dǎo)致過多的對象，而這些對象存在過多的交互及由此產(chǎn)生的相關(guān)性，對于所創(chuàng)建的整體式系統(tǒng)，很難維護(hù)而且不可能重用。這違背了面向?qū)ο笤O(shè)計的初衷。設(shè)計模式幫助克服這類問題，模式不僅描述如何構(gòu)造軟件，更重要的是，還描述了類和對象如何交互（特別是在運行時），明確地考慮這些交互及其結(jié)果會帶來更靈活、可復(fù)用的軟件。這區(qū)別于傳統(tǒng)的復(fù)用，傳統(tǒng)的復(fù)用是指代碼的剪貼復(fù)用、算法的復(fù)用、數(shù)據(jù)結(jié)構(gòu)的復(fù)用，其致命的缺陷是復(fù)用常常以破壞可維護(hù)性為代價的^[1] ，以設(shè)計模式為基礎(chǔ)進(jìn)行的系統(tǒng)設(shè)計，就是要使系統(tǒng)支持可維護(hù)性的復(fù)用，即在保持甚至提高系統(tǒng)的可維護(hù)性的同時，實現(xiàn)系統(tǒng)的復(fù)用。本文所討論的網(wǎng)絡(luò)性能管理系統(tǒng)應(yīng)用了門面模式、責(zé)任鏈模式、策略模式進(jìn)行系統(tǒng)可維護(hù)性的復(fù)用的優(yōu)化設(shè)計。?

4.1門面模式? ?

??? 門面模式要求一個子系統(tǒng)的外部與其內(nèi)部的通信必須通過一個統(tǒng)一的對象進(jìn)行。門面模式提供一個高層次的接口，使得系統(tǒng)更易于使用。這個接口使得子系統(tǒng)間的通信和相互依賴關(guān)系達(dá)到最小,并簡化類結(jié)構(gòu)[2]。在本文所描述的網(wǎng)絡(luò)性能管理系統(tǒng)中，其服務(wù)器端數(shù)據(jù)分析模塊、告警控制模塊、數(shù)據(jù)存儲模塊的主要功能分別由數(shù)據(jù)管理器、告警控制器、數(shù)據(jù)庫連接器來實現(xiàn)，這三個管理器又分別由DataManager、AlarmManager、DatabaseConnector這三個類來實現(xiàn)，在沒有使用門面模式前，客戶端與這些類交互的結(jié)構(gòu)圖如圖3：

???? 由圖可見，客戶端與服務(wù)器端內(nèi)部的多個類之間的交互錯綜復(fù)雜，客戶端與服務(wù)器端緊密耦合在一起，使得系統(tǒng)的維護(hù)與復(fù)用都很困難。在JMX架構(gòu)中，服務(wù)器端的所有功能模塊都要封裝成Mbean，才能與客戶端進(jìn)行交互，因此將增加JMX Agent管理這些Mbean的負(fù)擔(dān)，也增加了不必要的代碼，從而影響了系統(tǒng)的整體性能。使用門面模式就可解決這個問題，在服務(wù)器端設(shè)計一個門面對象，此對象接收客戶端的請求，并將請求委派到系統(tǒng)內(nèi)相應(yīng)的功能模塊中進(jìn)行處理，改造后的系統(tǒng)結(jié)構(gòu)如圖4：

??? 從圖可知，PerformanceServer作為門面對象，將客戶端與系統(tǒng)內(nèi)部復(fù)雜性分隔開，使得客戶端只需要與門面對象交互，而不需與服務(wù)器端內(nèi)部的眾多對象交互，提高了系統(tǒng)的可維護(hù)性的復(fù)用性能與可移植性，同時，被門面對象接管的不再與客戶端有直接交互的功能模塊可與門面對象封裝在同一Mbean中，減輕了JMX Agent管理負(fù)擔(dān)并去除了大量不必要的封裝代碼。?

4.2 責(zé)任鏈模式?

??? 在責(zé)任鏈模式中，很多對象由每一個對象對其下一個對象的引用而連接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。發(fā)出這個請求的客戶端并不知道鏈上的哪個對象最終處理這個請求，這使得系統(tǒng)可以在不影響客戶端的情況下動態(tài)地組織鏈和分配責(zé)任，^[3] 使得數(shù)據(jù)在服務(wù)器端的復(fù)雜處理對客戶端是透明的，即減低了客戶端與服務(wù)器端的耦合度。服務(wù)器端的數(shù)據(jù)分析模塊由流速分析器、主機(jī)分析器、數(shù)據(jù)池添加器、入庫控制器組成。這四個處理器組成一條直線鏈，其結(jié)構(gòu)圖如圖5：

??? 來自包數(shù)據(jù)采集器的流量數(shù)據(jù)在這條責(zé)任鏈中被進(jìn)行處理，鏈尾沒有處理功能，其作用是作為整條功能鏈的終結(jié)，數(shù)據(jù)到了鏈尾就不再往下傳遞。這條鏈中的每個功能模塊均實現(xiàn)同一個接口，每個模塊保存接收到的數(shù)據(jù)，對數(shù)據(jù)的副本進(jìn)行處理，在邏輯功能實現(xiàn)后，調(diào)用下一個模塊的引用，并將保存的原始數(shù)據(jù)向下傳遞。數(shù)據(jù)傳遞的不變性，令責(zé)任鏈可以對系統(tǒng)的各個功能模塊進(jìn)行明確的劃分，各個模塊之間互不影響，不管某個模塊是否處理數(shù)據(jù)，數(shù)據(jù)仍可在責(zé)任鏈中進(jìn)行傳遞，其它模塊仍可得到原始數(shù)據(jù)并完成其邏輯功能，這使得責(zé)任鏈功能的擴(kuò)展與維護(hù)變得輕而易舉。?

4.3 策略模式?

??? 策略模式的用意是針對一組算法，將每一個算法封裝到具有共同接口的獨立的類中，從而使得它們可以相互替換。策略模式可以避免使用多重條件轉(zhuǎn)移語句，它提供了可以替換繼承關(guān)系的辦法，可以動態(tài)改變算法或行為。[2]

??? 設(shè)計在服務(wù)器端的告警控制器對各項告警指標(biāo)，如流量、利用率、廣播包比例、錯誤包比例等進(jìn)行三種不同的測量方法后，根據(jù)告警算法監(jiān)測異常并實時的通知客戶端?？蛻舳丝梢詻Q定采用何種測量方法來監(jiān)測告警指標(biāo)。三個測量方法是：提供一段時間內(nèi)流量，測量其平均值；對瞬時流量進(jìn)行測量；測量某段時間內(nèi)的峰值（或最低值）。此時運用策略模式可以很好地解決這個問題。策略模式把行為和環(huán)境分割開來，環(huán)境類負(fù)責(zé)維持和查詢行為類，三種測量流量的方法則在具體策略類中提供。由于測量方法和環(huán)境獨立開來，測量方法的增減、修改都不會影響到客戶端與告警算法的實現(xiàn)，因此去除了測量方法與告警算法之間的耦合。由上面三種模式改造后，服務(wù)器端的總體結(jié)構(gòu)圖如圖6。