1.引言

2? 基于JMX 管理架構進行設計的可行性?

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

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

代理層：在本層中，公開了 JMX 代理的內部體系結構。JMX 代理是軟件組件，它向遠程管理組件公開一組標準化代理服務并通過 JMX 可管理資源的 MBean 接口直接控制這些資源。代理通過連接器或協議適配器與管理應用程序通信。?

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

??? 體系結構如圖1所示：?

??? 因此，JMX允許網絡管理系統(NMS)、企業管理系統(EMS) 和其它管理／控制應用程序管理基于 Java 平臺的軟件應用程序、服務和設備。JMX管理架構利用了當今最新的軟件體系結構設計中的最佳實踐，并以較低的實現成本提供了分布式的、兼容的、可擴展的和健壯的 Java 軟件可管理性的解決方案。

3? 網絡性能管理系統的體系結構?

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

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

4? 設計模式對系統設計的優化?

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

4.1門面模式? ?

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

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

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

4.2 責任鏈模式?

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

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

4.3 策略模式?

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

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