简介

J2EE (Java 2 Platform, Enterprise Edition) 是Web应用开发的主要标准。J2EE是专为大型企业设计一个Java平台，以满足他们对于数据处理的需求。它通过创建标准化的、可重复使用的模块组件，以及自动处理程序设计，简化了瘦客户（thin-client）端多层次环境中的应用开发，可以减少程序设计工作，降低程序人员的培训需要。

 

例如IBM、BEA、Sun和Oracle等许多供应商已经实现了J2EE标准，并且，他们现正在作市场推广，鼓励各企业使用他们的J2EE应用服务器进行英特网和企业内部互联网(Intranet)的应用开发。J2EE框架迅速发展并变得越来越普遍。在短短几年中，J2EE已经成为企业在创建以Web为中心、关键业务应用的过程中的首选平台。事实上，对于许多《财富》2000强公司来说，基于J2EE的应用服务器已经成为他们Web应用基础架构的核心。

 

 

 

 

目录

简介

J2EE应用的成功关键

应用实施

应用管理

监控上线的J2EE应用所面临的独特挑战

基于J2EE的Web应用的复杂性

J2EE基础架构的分布特性

传统的系统管理方法是不完善的

有效J2EE监控的要求

关注最终用户和整个业务流程

采用以业务为中心的方法

管理以用户为中心的SLAs

采用由上至下的分析方法

全面收集监控信息

关联最终用户体验和应用系统活动

寻找典型J2EE错误

现有J2EE应用管理解决方案的局限性

美科利业务可用性中心：适用于J2EE的全面性能管理解决方案

以业务为中心的IT管理

有效的J2EE应用管理：美科利的与众不同之处

360度实时监控

筛选诊断法

深层次诊断法——解决最棘手的J2EE性能问题

美科利生命周期探测器：以最少的人力资源实现最大化的可见性

为集群环境提供的支持

总结

J2EE应用的成功关键

现在比以前任何时候都需要部署并维持高性能的Web应用。您一旦决定采用J2EE标准开发基于Web的应用，就需要在整个应用生命周期中采用最佳的软件和服务来优化基于J2EE应用的质量、性能和可用性。该应用生命周期应该与IT管控、应用实施和应用管理这几个主要阶段并驾齐驱，共同前行（见图1）。
  

 

 

应用实施

应用测试将有助于衡量出应用的准备就绪情况，并使预先部署好的应用质量达到最大化，以满足业务和最终用户的要求。为了在应用开发的各个阶段能识别并隔离问题，您必须进行功能、负载、性能和可扩展性测试。

 

当您把应用和系统投入生产时，关键业务部署阶段就开始了。生产调优将帮您衡量性能的准备就绪情况，最大化各个应用的效率。生产调优的一个重要副产品就是性能基线的创建。这些基线将有助于评估最终用户的线上交易情况，并定义服务水平协议（SLAs）。

 

应用管理

应用部署完毕后，机构必须不断验证：应用对于最终用户来说是可用的；其性能维持在可接受的限制范围内。维持一致的、高水平的性能的唯一方法就是进行应用性能和可用性监控——而且该监控方案必须能关注于最终用户体验，采用由上至下的方法，这样才能自始至终地帮您全面而彻底地了解系统性能情况。

 

监控上线的J2EE应用所面临的独特挑战

电子业务应用是您机构的生命力。您依靠这些应用来控制您的供应链、库存和资源。更重要的是，您依靠它们来帮您管理您与供应商、合作伙伴，当然还有客户之间的关系。一些公司花费了上百万美元的金钱去建立最先进的Web应用，但仍然在丢失客户。为什么？因为，在这些网站创建完毕并开始运行后，它们缺少那些能监控和改进网站效率和性能的工具。虽然恰当的监控是保证J2EE应用的性能和可扩展性的关键点，但是J2EE环境监控本身就面临着独特的挑战。

 

基于J2EE的Web应用的复杂性

想要找到一种灵活的性能管理方法，它既包含内部J2EE环境，还包含起支持作用的基础架构，这本身就是种挑战。支持那些基于J2EE的Web应用的基础架构是一个复杂的、多层次的结构，其中包括客户机器、负载平衡器、防火墙、Web服务器、应用服务器、安全服务器、交易服务器、数据库服务器以及这些组件之间的网络链接。同时，由于J2EE应用服务器是建立在无数个组件基础上的多层次结构（见图2），所以其本身也具有内部复杂性。应用服务器通过某个Web服务器接收到客户发出的HTTP要求，然后采用各种J2EE组件（例如：servlets、JSPs、EJBs和helper classes）和各种外部实体（例如：数据库和大机系统）处理这些要求，再发回HTTP响应。如果我们知道，许多J2EE部署环境中的两个或更多的应用服务器（结果往往是JVMs）运行在由许多个处理器组成的服务器上，那么我们就很容易理解，为什么有效的监控J2EEWeb应用是一项令人望而却步的任务了。

  

 

J2EE基础架构的分布特性

理想状态下，那些基于J2EE的Web应用的组件应位于同一个地区，这将有助于您的顺利操作和控制。但事实往往是：在外方的监管下，不同的组件分布于各个分散且相距遥远的地方。并且，鉴于英特网“永远为业务而开放”的理念和最大程度缩小用户之间地理差距的特性，J2EE应用的创建和管理方法必须能为当今英特网地球村中任何一个地区的客户提供24x7的全天候服务。网站监控器和工作人员必须也要适应不断变化的基础架构，与之并驾齐驱。

 

传统的系统管理方法是不完善的

例如企业系统管理（ESM）等传统的监控和管理方法在监控J2EE环境方面的成效是有限的。因为它们对硬件和软件、客户和服务器、后端和最终用户之间采用一对一的对应关系，这不能反应出某个基于J2EE的Web基础架构的真实状况。相反， J2EE应用的性能决定于Java虚拟机(JVM)和其无数个调整参数，而并非决定于物理硬件和操作系统。并且，多个J2EE应用可以相互集成，或与大机应用、Web服务、甚至与以上所有应用服务相集成，使中间件层成为一个相互依存的网络。

 

 

有效J2EE监控的要求

您一旦认为J2EE应用管理解决方案对于您的电子商务应用具有至关重要的作用，您还需要考虑以下问题：哪种解决方案可以使企业获取最高的投资回报率（ROI）？以下，我们将讨论最佳J2EE性能管理解决方案应具备的条件。

 

关注最终用户和整个业务流程

最终用户客户是业务的最重要资产。无论是否存在“真实”用户在进行交易，我们都能并且应该在全天24小时、一周7天中不间断地衡量和报告一个Web应用的最终用户体验情况。否则，该解决方案如何能证明：所有交易对于最终用户来说都是完整而令人满意的？当产生某个影响最终用户性能的问题时，您又能如何自动得知相关情况呢？

 

采用以业务为核心的方法

如果您采用一个以业务为核心的方法来管理您的应用，您就能在性能和可用性问题影响业务和底线之前，就能识别并解决这些问题。这种方法就要求您的IT系统、基础架构和业务流程相互统一，共同创造出业务成果。最佳的性能管理解决方案应能帮您管理主要业务流程和J2EE应用所传送的业务交易。

 

管理以用户为中心的SLAs

J2EE性能管理解决方案必须能使企业和服务供应商从用户中心角度去管理服务水平——对业务的健康状况和服务水平状况提出有价值的见解。同时，它也必须能为分布式环境中的各个复杂业务应用提供SLA顺应性报告。机构应该能够定义、衡量和跟踪以最终用户体验为基础的性能服务水平，而不仅仅是能够监控基础架构内部单个silo组件的服务水平。

 

采用由上至下的分析方法

监控应用性能和可用性的第一步就是要能从系统上下整个范围内了解您的应用的健康状况。由上至下的信息显示是全面了解您的J2EE系统的最佳方法，它能让您便捷地了解到哪些应用运行正常，那些应用存在问题，需要进一步检测。然而，对于故障修复来说，仅仅只有这种由上至下的视图是远远不够的；所以下一步就是要进一步深入分析应用，把存在的性能问题和产生这些问题的根本原因通过粒状度量法进行关联。

 

收集全面的监控信息

正如我们已经提到的，基于J2EE的Web基础架构具有一个复杂的结构。因此，我们不仅应该从应用服务器上收集性能和可用性数据，而且应该从其他一切与用户要求响应或业务流程响应有关的系统和组件中收集相关数据。这些相关的组件包括数据库、安全系统、代理服务器、交易服务器和负载平衡器。当然，所面临的挑战就是：以尽可能最低的操作费用，收集足够的数据来满足高水平的、由上至下的信息表述的需要，以及问题详细分析的需要。

 

关联最终用户体验和应用系统活动

从那些J2EE应用和系统所衡量取得的性能和可用性标准必须与最终用户经历相关联起来——例如：把从应用服务器衡量取得的JDBC呼叫数量与某个特定业务交易相互关联。一旦建立了这种相关性，您的IT员工就能迅速找到产生性能和可用性问题的根本原因，并且能以最快的速度解决这些问题。另外，相关性还有助于优化最终用户状况警报和错误查找工作。

 

寻找典型J2EE错误

在J2EE平台上开发Java应用，会产生其本身所独有的各种性能、可用性和可扩展性问题。监控J2EE应用时，您的问题解决方案必须能对以下普通J2EE缺陷作出响应：

 

l          低劣的代码、设计和结构，例如内存泄漏、数据库连接数不足、过多的远程调用、大量的限制重复使用的有状态对象（stateful objects）和未释放的JDBC连接。

l          错误的参数设定，比如：数据库排队（Queuing）和死锁（Deadlock）、不合理的缓冲池大小、不正确的执行线程数、以及过小或过大的JVM内存量。

l          不合理的容量规划，无论是低估了并发用户的数量和资源，还是高估了所需容量，都将导致金钱的浪费。

l          不合适的集群，它将导致不正确的负载平衡，由于会话保持而造成的额外性能过载，并且如果该会话始终工作于同一节点，将会削弱应用可用性（例如”粘滞” Sticky会话）。

 

现有J2EE应用管理解决方案的局限性

新一代的基于J2EE的应用所需要的解决方案应该具有以下特点：主动性、反应性、采用自上而下和自下而上两种分析方式、能从商业和IT的角度出发提供整个应用基础架构的性能和可用性状况。

 

然而，市场上存在的几种J2EE应用管理解决方案，其中大多数采用由下至上的以IT为中心的方法，只能对J2EE silo进行监控。这些问题解决方案仅仅从J2EE应用服务器收集性能指标，所以无法向操作者和业务使用者提供可用性和性能的整体情况信息，只能从组件水平上提供应用性能的零星描述。为了能有效管理那些基于J2EE的应用，操作人员和业务部门必须从最终用户角度出发了解应用性能，并且作出相应分析，以保证最终能完成变更，使应用支持下的业务交易得以流畅地展开。

 

最后，作为总结，让我们一起来看一下传统的“由下至上、以IT为中心”的传统方法在进行性能监控时所缺乏的方面：

 

l          采用以业务为中心的方法：现有的以IT为中心的方法无法让您看到J2EE性能问题对业务产生的影响。采用以业务为中心的方法来管理您的J2EE应用，这是非常必要的，它能帮您随时了解业务的发展动向。

 

l          管理以用户为中心的SLAs：现有的silo监控方法无法定义，跟踪和管理那些满足业务目标的服务水平。这样，您的性能水平就无法保持一致性，无法主动发现并解决问题，从而，您就无法得到最大的投资回报率和利润。

 

l          从最终用户角度关注整个业务流程：现有方法在监控代理服务器时仅仅争对应用服务器，而您“真正”的最终用户分布于全球各个地区，他们需要穿越各种组件（那就是：ISPs、防火墙、网络）才能到达应用服务器。结果往往是，silo解决方法所收集的数据只能衡量出有限的空间范围内的性能，所以无法真正确认最终用户是否能及时持续地接收到正确的内容。

 

l          由上至下的方法：由下至上的方法所提供的信息内容比较单一。例如，执行某个SQL语句所需的时间是500毫秒。然而，由上至下的方法会告诉您，由于应用宕机，20％的用户无法完成购买交易。它能帮您跟踪某个需要500毫秒执行时间的SQL语句。跟踪完成后，您就能了解到，为什么该SQL语句所需的时间占到整个业务流程执行时间的30％多。

 

l          相关性：相关性能在视觉上及概念上帮您把后端活动和最终用户体验联系起来，从而让您了解到Web应用活动对业务产生的各种影响。然而，“由下至上”的解决方法仅仅以零星的数据来显示性能信息，使操作者不得不绞尽脑汁猜测如何才能把这些数据转换成有关业务交易性能的有用信息。

 

l          有效的监控方法：监控时采用无代理方式呢，还是以代理为基础？主动监控还是被动监控？为了能以最低的性能费用在最大的范围内收集数据，对J2EE活动作最完整的分析，您最好能组合使用这些方法。然而，大多数的解决方案只采用一种被动的、基于代理的方法。监控的组合方法将使您能在J2EE基础架构中跟踪问题，发现其根本原因，判断系统和应用的健康程度，并以最低的费用对最终用户使用状况作出完整分析。

 

美科利业务可用性中心：适用于J2EE的全面性能管理解决方案

美科利业务可用性中心（Mercury Business Availability Center™）为您的操作和应用支持小组提供了统一的解决方案，使他们能迅速监控，诊断并优化生产应用，从而最大化J2EE应用的性能和可用性。它使各个小组能清楚了解用户、业务流程、应用以及那些下至组件、方法、甚至代码水平的系统层。最终，高性能的重要应用保护了SLAs和底线。

 

美科利业务可用性中心所涉及的应用和技术覆盖范围是独一无二的，其中包括了J2EE、.Net、Web服务、ERP、CRM和主要框架环境。

 

以业务为中心的IT管理

美科利业务可用性中心包含三个层次：应用、平台和监控器。六大应用是：

 

1. 美科利服务水平管理（Mercury Service Level Management™）: 它使您能管理服务水平，并为分布式环境中的复杂业务应用提供SLA顺应性报告。

 

2. 美科利系统可用性管理（Mercury System Availability Management™） (和Mercury SiteScope®): 它使您能顺畅地部署并维持整个企业基础架构监控方案，保证百分之一百的覆盖率。

 

3. 美科利应用映射（Mercury Application Mapping™）：它能提供实时可视性，让您了解应用和基础架构之间的动态关系。

 

4. 美科利应用管理分析（Mercury Application Management Analytics™）: 它能创建高级报告，对美科利和第三方数据来源进行针对性分析，从而把操作数据转换成有用的信息。

 

5. 美科利最终用户管理（Mercury End User Management™）: 它能从最终用户角度主动实时监控应用可用性。

 

6. 美科利诊断法（Mercury Diagnostics™）: 它提供了业内第一个由上至下的生命周期方法，在应用的整个周期中管理，监控，诊断并解决主要问题。

 

这些应用建于美科利应用管理基础（Mercury Application Management Foundation™）之上。美科利应用管理基础能提供共享的工作流、数据、脚本、和应用/基础架构监控器，能整合主要应用管理流程，从而采用最佳实践方案去解决问题。它还能协助您的机构快速部署美科利业务可用性中心——其TCO比传统的客户/服务器解决方案更低。美科利公司为您提供集中的、基于Web的管理和配置方式，使您的机构更易管理、更安全、且更易衡量。它包含内置的最佳实践和模板，以及适用于超过65种系统的一整套模拟业务流程、真实用户、客户桌面和基础架构监控器。

 

如果您决定使用美科利产品，适用于美科利业务可用性中心的托管服务（Mercury Managed Services for Business Availability Center™）能为应用管理卓越中心提供一整套的部署方案，美科利的专业小组将昼夜不停地提供监控服务。除了提供一个由数据库、应用和安全专家支持的预先部署完毕的构架外，美科利公司还提供持续的指导培训服务，确保您的内部小组准备就绪，能够管理您自己的卓越应用管理中心。美科利托管服务使您能关注于关键IT和业务，而不再是日常系统管理，从而精简了您的应用管理流程，降低美科利业务可用性中心的TCO。

 

有效的J2EE应用管理：美科利与众不同之处

美科利业务可用性中心的特性是专为监控、诊断和管理基于J2EE的Web应用所设计。凭借与Sun、BEA、IBM和Oracle等主要IT供应商多年紧密合作的经验，美科利的专家们设计出了业内领先的J2EE应用诊断方法。

 

凭借我们的旗舰产品适用于J2EE的美科利诊断法(Mercury Diagnostics for J2EE)，美科利公司将帮您：

l          在影响客户之前，主动检测到这些问题

 

l          迅速把问题和系统或应用层隔离开

 

l          精确指出根本原因所在的某个应用组件

 

凭借美科利业务可用性中心和适用于J2EE的美科利诊断法，您的机构能从某个控制台就能监控J2EE应用的性能，当出现性能差异时，您能接收到警报，识别问题并诊断问题原因。它是唯一一种能帮您实现以下功能的方法：以由上至下的分析方式显示性能和可用性信息；24x7全天候不间断衡量最终用户和业务流程；在防火墙内外以及应用本身内部，把性能和可用性问题与其根本原因关联起来。

 

从最终用户性能交易和J2EE的Web基础架构中的组件中，美科利诊断法收集了粒状性能数据，然后把它加工成有价值的性能、可用性和服务信息。一旦性能数据被收集到，它就被送回到美科利的中央诊断服务器中进行加工、储存和关联。

 

 

当在美科利业务可用性中心中检测到一个性能问题时，它就能通过寻呼机、电子邮件、手机或SNMP trap向操作组发出警报。这个可配置的警报系统能与现有警报通知程序相集成，以便在问题出现时尽快发现并处理。另外，美科利业务可用性中心在错误恢复脚本基础上进行纠错，自动解决性能问题。这些功能都能帮您进一步确保应用正常运行时间的最大化。

 

适用于J2EE的美科利诊断法能做到实时监控，进行交易细分和筛选分析，并能对最棘手的J2EE问题进行深层次的诊断。

 

360度实时监控

首先，通过与美科利业务可用性中心控制面板的整合，美科利诊断法让用户能由上至下地了解J2EE应用的总体健康状况。这些控制面板使您能清楚了解Web应用和系统的信息，其中包括业务流程和交易的状态、应用组件的健康和性能状况、以及那些Web服务器、应用服务器和DB服务器等支持基础架构的高水平状态。美科利业务可用性中心的控制面板为IT操作人员提供了全面的最终用户、应用和系统层监控，使他们能迅速识别在J2EE生产环境中的最终用户性能和可用性问题。

 

 

正是从那里，应用支持工程师们能对某个Web应用的性能和可用性进行更深入分析，然后，把他们的发现结果与先前创建的基线和SLAs相比较。

 

筛选诊断法

美科利诊断法不仅显示了客户方面的交易响应时间，而且也显示了服务器方面的响应时间，从而提供了完整的性能状况信息。交易响应时间被进一步细分为两种：从客户机器所衡量得到的组件响应时间（如：DNS时间、SSL信号交换时间、或下载时间）；从应用服务器所衡量得到的J2EE组件响应时间（如：Servlet 时间、Session EJB时间或数据库时间）。这样，您就能迅速而直接地找到确切的瓶颈所在点，保证该问题被进一步提交给正确的专业小组。

 

图6中我们可以看到从应用服务器进行衡量时的四大业务交易的细分结果。J2EE交易细分清楚地显示，“购买书本”交易的性能低下，数据库调用时间占到整个交易时间的83％。深层次分析将帮我们直接找到存在问题的SQL语句，然后进一步调查该性能问题。

  

美科利诊断中心采用了独特的方式来观测每一个交易和分析各种因素，所以它的性能也是独一无二的。其他监控工具都无法使