《JMX in action》读书中文随笔<1> 企业资源管理概念-CSDN博客

前面的话

近来闲的蛋疼，读了一下《JMX in action》，决定对文中内容以中文进行整理、总结成篇，以作日后备查之需。

笔者将该系列随笔（后面简称“随笔”）分为四大章节：引入章节、基础知识章节、高级主题章节、实践应用章节。

引入章节包含了——“资源管理概念”、“JMX是什么”、“hello world 第一个简单例子”，旨在对JMX的来龙去脉，基础概念进行导入；

基础知识章节包含了——“Standard MBean 标准MBean”、“Dynamic MBean 动态MBean”、“Notification 通知模型”、“Model MBean 模型MBean”、“探索MBeanServer”、“Distributed Layer 分布式层”，涵盖了对JMX各个基础组件的解读与使用；

高级主题章节包含了——动态加载、关系服务、监控和时间管理等一般不太常用，但非常有趣的功能组件；

实践应用章节包含了——实际项目中对JMX的应用，如结合HypericHQ对由JMX导出的统计数据进行监控，探讨如何使用JMX对系统进行合理架构，简单阐述了一些知名开源项目如何对JMX进行支持（如Apache-MINA）。

需要声明的是：

1、之所以写该“随笔”，主要是笔者觉得直接看英文比较麻烦，看一次就够了（真懒啊）；

2、“随笔”对原书中的概念、描述、结构进行了令人发指的疯狂照搬抄袭，很多文字仅仅只是做了原文翻译，并加入了笔者极少量极浅显的个人愚见，欢迎拍砖；

3、“随笔”对原书中的一些实例进行了一厢情愿的“现代化改造”，对原书中示例所依赖的，但当前不太常用的技术进行了惨无人道的“抛弃”或“替换”，如jini，尽力保证每个实例都是直接拷贝可运行的；

4、实例在jdk1.6下编译通过；

5、该系列文章是小弟弟第一次试水，必有不尽不妥之处，请多多包涵小弟弟第一次上岗的不给力。。。

企业资源管理概念

在开始学习JMX的任何一点点知识之前，我们首先要做的，是了解JMX为何要存在，存在的理由是什么。

一个典型的信息企业，内部可能存在着各种各样的硬件设备与软件系统，这些设备与系统数目繁多，并且可能以完全不同的方式进行部署，完全不同的网络协议进行交互。我们将这些硬件设备与软件系统统称他们为资源，企业内部的IT人员需要通过某种方式了解到资源是否正常，比如硬件网络设备是否正常地进行网络IO数据转发？网络应用系统是否正常地收发请求与回应？业务系统的TPS（每分钟业务数）数量是否正常？总而言之，IT人员需要能够对资源进行“管理”。

这里提出企业资源管理的概念定义：提供一系列工具与方案对资源（一般指硬件设备与软件系统）进行管理。在典型的信息化企业场景中，资源管理意味着可以通过工具导出企业资源的健康状态报表，而相应的企业IT人员可以根据该报表中可能存在的问题（如系统挂掉或业务处理能力迅速下降）来采取相应的手段进行应对。这就好比你去看医生（IT人员），医生通过听诊器（资源管理工具），来获取到你的健康情况（企业资源健康状态报表），并开出相应的药方（恢复手段），来治疗你的病情。

然而，在一个实际的企业中，因为种种原因（大多为历史遗留），导致现存的设备与系统是如此TMD不同，如此TMD错综复杂，IT人员如何能够正确地了解到资源的健康状况？莫非我们对每一个资源都编写一套不同的监控工具？这确实可以解决一些问题，不过，这开发成本和学习成本也太高了吧，万一当前的监控工程师跑路了，新来的哥们是不是还得重新学一遍？这真是眉毛胡子一把抓，明显没有效率嘛。

到这里，我们把问题提出：合理的企业资源管理解决方案是怎么样的？

下面我们来分别说一说针对这个问题的几种可能方案，包括“不好的方案”，“理想化的方案”和“合理的方案”。在开始之前，我们先定义一个业务场景：有一个在线自行车商店，客户可以通过浏览器访问该在线商店，并购买相应的自行车或骑行服。该在线商店系统包含了web服务器，应用服务器与数据库。为保证服务的可用性，我们又安装了一套备选的服务，备选服务也包含了相应的web服务器，应用服务器与数据库。当主服务出现问题的时候，应该能够通过故障转移设备切换至备选服务，并将请求路由至新的服务。

系统逻辑框图如下：

“不好的方案”（但该方案在当下大多数企业中却是长期存在）是怎么样的呢？

下面是“不好的方案”的逻辑框图：

如上图所示，针对硬件设备（如故障转移设备，承载各服务器的硬件主机，网络路由设备等）基本上通过SNMP（Simple Network Management Protocol 简单网络管理协议）来了解与监控硬件设备的可用性与健康性，并将可用性与健康性信息保存在MIB（Management Information Base 管理信息库）之中。基本上，当下的硬件设备提供商都对硬件产品内置了对SNMP与MIB的支持，但是，针对SNMP进行开发并不是一件简单的事儿，开发与维护的困难程度让人望而却步。

在软件系统层面，多数软件较少考虑系统关键参数在运行时的可配置性（原作者在写该书时是21世纪初，当下的情况已有改观，这里只是强调软件运行时参数配置的重要性），实际上，很多软件系统可配置的部分仅仅是由容器级别来提供的，如Web容器或应用程序容器，太过简单，并不实用。对于软件系统的监控与统计数据收集，也没有一个通用的，可重用的解决方案。对于每一块（如数据库，应用服务器，web服务器），开发人员可能都需要编写特定代码来提供监控与统计数据收集，而监控人员也需要面对不同的监控控制台，复杂程度可见一斑。

“理想的方案”

下面是“理想的方案”的逻辑框图

该方案能够保持对硬件设备与软件系统的健康性进行持续监控，如果发现设备挂掉，能够自动选择一个备选设备，并将业务处理重新路由至新设备，然后通知到相应的问题负责人。现实中，比如我们的web服务器挂掉了或因为请求量太大导致客户体验下降，此时资源管理系统能够自动将新的web服务器加入，提供服务，以减轻负载，并将该问题通知相应的负责人。

理想的资源管理系统不仅能够“感知”应用程序的健康状况，而且也有能力理解应用程序的内部结构与机制。举个例子，管理系统能够迅速生成业务系统中的成功处理与失败处理的对照报表。还可以根据软件系统与硬件设备的运行状况调整系统内部的处理线程数量。

我们常说，理想是美好的，现实是残酷的，我们也遇到了这样的问题。理想的资源管理系统看起来非常好，但是，实现它需要更多的开发资源，需要有更多的工作要做。有时候看起来，似乎不切实际，这也许就是为什么它得名为“理想的资源管理系统”。。。

最后，我们隆重推出“合理的资源管理方案”，它是对“不好的方案”和“理想的方案”的一个折中，既不是眉毛胡子一把抓，各自为政，也不是要构造一个乌托邦的世界。

还是以之前定义的自行车电子商店来说，“合理的方案”应该具备下面的特性：

1、能够监控硬件与容器（一般指web容器或应用容器）的健康状态

如我们需要知道web容器的健康状态，以及承载它的硬件主机的健康状态（当然，硬件网络设备仍然通过导出SNMP接口来反映它们的健康状态，web服务可以让你通过浏览器来知晓它的健康状态，数据库可能也以某种机制来提供它们的状态查询）。

2、能够对应用程序进行灵活的运行时参数配置

如你已经开发完成了自行车电子商店系统，原先商品展示时每页显示50个商品，现在需要改为每页显示30个商品，需要能够具备在运行时能够做出这种变更的能力；又如数据库负载较高，连接数较高时，能够在运行时调整数据库的连接数以适应需求。

3、能够收集系统统计数据

在自行车在线商店中，你也许希望能够收集一些重要的系统统计数据。如某时间段的页面访问量及实际购买量；又如，外部对系统web服务的非法尝试请求，这些数据应该都可以被保存到资源管理系统中去。

4、能够运行时调整日志级别

当你需要定位系统bug时，可能希望通过调整日志级别，通过输出的日志信息来确定到底问题出在哪儿。