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。