存储专家谈：在J2EE平台上实施应用性能管理

 绪言
  
    显而易见，信息技术现已成为企业核心竞争力的一个重要组成部分，是业务成败的决定因素。信息技术通过不断的技术创新，一方面不断完善自身的体系结构和实施手段；另一方面，它引导新业务模式的产生，成为生产力提升和变革的原动力。正是由于信息技术对于企业经营模式，乃至整个社会沟通方式所产生的显著而巨大的影响，它已经从一个辅助性的角色，转变成为众人所瞩目的重点话题。     让我们把目光从整个社会的大范畴聚焦到一个企业，信息技术的发展已经到了一个极制。7×24的全天候访问，跨越软硬件平台的无限可扩展性，简单、一致的用户自助服务界面…诸如此类的苛刻要求，都是为了满足业务部门“更快、更高、更强”的要求而制定的。然而，在信息系统满足了上述的种种要求之后，其自身的结构也变得异常的复杂。在一个典型的企业应用环境中，从后台的硬件存储开始，往往要通过、应用服务器、Web服务器和客户端应用几个技术层次来实现业务操作，其中还会由若干承担具体任务的中间件产品和技术扩展，来提供诸如均衡负载、高可用性、可伸缩性等企业计算所必须具备的功能。下面的图示反应了这类企业的基本技术构成元素和层次：     如此复杂和功能强大的信息系统为企业业务目标的实现提供了技术上的保障，然而，这还不足以实现提高生产力的最终目标。一个企业应用的评估标准应该有两个，一个是可实现性，一个是运行效率。对于前者，我们通过基础架构和技术组件来达成，而后者，传统的实现方法是通过专门的维护团队来保证的。对单一类型的应用而言，“效率”，也就是“性能”，通过这种方式，是能够得到保证的。无论是数据库，还是应用服务器，乃至在更加复杂的定制应用和打包应用领域，都有厂商或者集成商的专业技术人员来为之提供支持服务。对于用户而言，无论是依靠厂商的服务，还是自己拥有的系统维护团队，对于单一类型的应用系统尚且能够确保性能，尽管，随着特定技术之间的交叉、融合，只单纯把握一种技能的人员，已经越来越难以应付系统性能所提出的挑战。
  
    在进入21世纪之后，随着Web技术成为数据展现和操作访问的事实标准，企业利用这个平台，将原来分散的子系统进行着整合。尽管应用整合可以通过多种手段来实现，但J2EE的出现，由于其天生具备良好的开放型和可扩展性，使之在应用整合和开发的过程中发挥了愈来愈显著的优势。 
  
    采用J2EE技术部署基于Web的应用，已经显著改变了服务的基本经济原则、竞争力和用户界面。基于Web的应用迅速代替成本更高的“人员协助”传统服务。这种新一代应用为企业提供了独一无二的机会，使之能够利用传统系统，在多个服务“层”之间分配应用，充分利用新计算技术的优势。虽然这些基于Web的应用为公司提供了无与伦比的灵活性，但更加复杂的应用却使所在的基础设施面临不断的改变和超高的负载，应用性能的下降所导致的不良用户体验，反而降低了客户的满足率和忠诚度。
  
    当今的用户都期望能在世界各地随时访问网站。假如应用的用户发现屏幕底部的蓝色进度条从左到右前行的速度过慢，他们就会离开该网站，而且通常不会再次访问。同样，假如服务水平没有达到期望值，现有客户端通常会重新使用陈旧的、高成本的旧用应用来处理业务，或者开始关注其他供给商或服务。从而，企业的治理者熟悉到，由于目前业务对于信息系统的依靠性，假如不能遏制应用性能下降导致的客户流失，假如不能克服复杂性所导致的迟缓的故障排查，对于J2EE在内的新技术的使用都会适得其反，导致业务的下滑。
  
    方法论和解决方案
  
    在这种情况下，一种对于应用性能进行监控、报告、分析、改进以及趋势猜测的技术应运而生，我们把这类技术成为应用性能治理（Application Performance Management）。它具有以下几个鲜明的技术特色：
  
    1．APM着眼的是应用系统整体的性能治理，而非仅仅针对某个技术层次的“烟囱式”的解决方案。
  
    从性能指标的检测开始，APM就是以最终用户的响应时间为主要的衡量标准，在第一时间将问题定位于某个技术层次；在问题得到修改之后，它也会从应用整体响应时间的角度，测量改进之后的性能。
  
    2．APM的视野不仅足够宽广，而且足够深入。
  
    对于每个技术层次，APM都能够溯本求源，准确定位导致性能下降的根本问题。而且，它提供专家级的建议，通过最佳实践帮助使用者尽快进行修复。
  
    3．APM考察应用系统的性能依据，来自于用户的真实操作数据。
  
    同比传统性能调优工具使用的模拟数据，APM才能够收集到用户实际的体验，将使用习惯、业务波动和技术指标综合考虑。显而易见，这种数据只能来自于生产环境，而APM依靠其对于应用超低的负载，能够实施7×24的长期监控，是那些产生高额负载的性能调整工具所不能比拟的。
  
    4．APM拥有专门的数据存储。
  
    APM将采集的数据经分析之后存放起来，而非在考察之后就抛弃，或者仅仅保留短时间的性能数据。只有这样，使用者才能够通过对于长时间的历史记录的分析得到结论，从而了解：过去曾经发生过什么，现在正在发生什么，以及今后即将发生什么。这就使得，APM不仅仅是一个在性能问题出现后进行补救的工具，而且能够为系统的维护团队提供预警信息，在性能问题真正开始影响用户的使用之前，就将其改正，保证为用户提供一个性能可靠，坚如磐石的应用系统。
    VERITAS i3 for J2EE就是一种典型的APM解决方案，它基于一种旨在便捷地对应用性能问题提供快速隔离、分析、纠正和校验的方法论，由以下5个阶段构成：

•     1.检测 ――识别并且显示性能问题的症状
•     2.查找 ――识别问题来源，将其隔离在某个技术层次
•     3.聚焦―― 发现问题的根源所在
•     4.改进――提供基于最佳实践的建议，以改进性能
•     5.验证――确保实施的措施能够达到预期目标

    以上的五个步骤依照以下顺序执行：

• 1．使用VERITAS i3 for J2EE的告警功能，进行主动和/或被动检测。这种告警可能发送到相应的基础架构组件、组织或个人，此外，负责性能的组织中的相关人员可以长时间检测服务，同时查看各种进程(如EJB、URL)的性能趋势；
• 2．诊断专家们可以端到端地查看应用，根据每个技术层次在响应时间中所占的比例，查找是那个技术层次导致性能降低；
• 3．在将问题聚焦到某个技术层次之后，通过“钻取”功能，彻底定位根源问题；
• 4．VERITAS i3提供经过验证的最佳实践，协助使用者改正应用问题。它甚至可以同特定的应用服务器（如BEA Weblogic）紧密关联，取得和改写某些配置参数；
• 5．在将改进真正提交到生产环境之前，VERITAS i3 for J2EE提供测试功能，以验证预期的效果是否达成，并且确定没有对相关应用的性能造成负面影响；

    通过以上的描述我们能够看到，VERITAS i3 for J2EE是一个集成的应用性能治理解决方案，它专注于确定用户体验和服务水平。
  
    它能够识别端到端的资源占用情况，从浏览器开始、跨越J2EE应用服务器，通过数据库一直到物理存储器的监控和检测应用性能情况，以用户响应时间为统一的标准来衡量各个技术层面的性能。这种方式，避免了负责各个技术层面的厂商和技术人员相互推卸责任，大大提高了隔离问题的速度。
  
    在确定问题之后，深度钻取的能力又向使用者提供了专家级的修改建议，协助快速修改问题。所以，我们可以看到，VERITAS i3 for J2EE的视野足够宽广，它覆盖企业应用的广泛领域；而且深入得足够彻底，它可以从代码，甚至物理存储得角度来进行性能的治理。
  
  VERITAS i3 的产品组成分为Insight、Indepth和Inform三个部分。这些产品无缝集成，共同关注要害应用组件?D?D这样就提供了一个完整的端到端性能治理解决方案。此外，VERITAS i3的每一个组件都能作为一种独立产品单独运行，以满足非凡环境和应用的需求。下图说明了VERITAS i3的体系结构组件。     Insight ――“什么原因导致运行缓慢?”
  
    当前的应用利用了多层体系结构，以提供多功能性，但这些体系结构却使我们很难确定性能降低的原因。Insight带有TotalCorrelation?，能够测量所有体系结构层(从URL到SQL)的响应时间，并将响应时间按层分段，从而确定“什么原因导致运行缓慢?”。
  
    Indepth ――“应该怎样进行修复？”
  
    在整个IT基础设施上，全天候地捕捉要害性能指标（KPI），确保无论何时开始出现性能降低，都能识别出问题。然后利用SmarTune?，钻取到部件级技术，如Web服务器、应用服务器、中间件、数据库以及存储器等，以自动确定最终的问题根源，生成专家调节建议。Indepth可识别“为什么”产生问题，以及“如何”修复问题。
  
    Inform ――“现在是否存在性能问题？过去有没有？未来会不会有？”
  
    了解应该“何时”专注于性能问题，与“如何”修复问题同样重要。假如没有把握趋势、基线、期望值和告警，则很难有效治理应用性能。即使发生最稍微的性能降低，Inform 也能发出及时通知，从而提供最充裕的时间，便于用户使用SmarTune提供的调节建议。无论通知的原因是无法达到服务水平，或是性能标准开始降低，用户都能及时收到信息。
  
    VERITAS i3 包括VERITAS Performance     Warehouse，该产品为相关端到端的数据历史提供通用库，从而实现趋势分析和特定时间性能审查。该库能够导出数据，供其它分析工具使用，也能导入应该包含在一些分析报告中的测量标准。 
  
    例如，假设您面对一个企业级Web应用，其中包括Web服务器、J2EE应用服务器、Tuxedo以及 数据库，您应该选择VERITAS i3 for J2EE 解决方案对其实现性能治理。其包括所有必需的功能，可以查看实际的用户响应时间，分析端到端的资源占用情况，提供对Web服务器、J2EE服务器、Tuxedo服务器和数据库的统计指标。您将能够钻取到Java方法调用，了解JVM中具体设置对于的性能的影响；能够钻取到Oracle数据库中，了解SQL语句的使用情况，检测数据库对象的运行效率；最终清除应用组件之间的冲突，保证高效率的应用性能。
  
    VERITAS i3 for J2EE关注应用的整个生命周期
    VERITAS i3 for J2EE不仅着眼于生产系统，并且能够服务于开发、质量保证部门：     在开发环境中，该解决方案能为我们测试系统和了解性能提供极大的帮助，在设计和体系结构问题在生产系统中影响到终端用户之前，提早捕捉这些问题。SmarTuneTM 提供的全面数据捕捉和自动分析功能，有助于应用工程师有效地确定开发工作的优先级；
  
    在质量保证、测试过程中，VERITAS i3 for J2EE提供了统一的测量标准，并且凭借独特的自动记录功能，质量保证和开发部门能够将大量记录保存在文档中；
  
    总结
  
    今天，IT 企业面临的挑战是：满足终端用户不断增长的高性能需求。事实证实，在服务、内部生产力和创收之间，存在着直接关系。VERITAS 提供了业务性能治理解决方案，以应对这些挑战，这些解决方案能够协助企业确定造成性能问题的原因，以及性能问题给整个系统造成的影响。
  
    VERITAS i3 for J2EE 不仅能够应对这些挑战，还简化了基于Web的企业应用的开发和部署过程。使用VERITAS i3 for J2EE ，有助于企业治理和提高为终端用户提供的服务水平，控制成本，最大限度地优化运营投资的效率，从而为基于Web的应用性能治理设立了全新的里程碑。
  
    案例
  
    两年前，英国电信的互联网业务部门开发了一款全新的尖端网络中心系统称之为BT Openworld，用以提高ISP的性能和可用性，改进客户体验。这款网络中心系统用于客户订购、设备和自我维护，它基于分布式J2EE体系结构，使用BEA Weblogic应用服务器和中间件Tuxedo，系统使用Oracel数据库，横跨多台Sun Unix服务器，并连接到远程数据库和订单处理系统，以进行客户治理和宽带设置。
  
    “如同一辆汽车，您被告知它的速度是120英里/小时，但事实上只达到80英里/小时。仪表板没有显示问题可能出在何处，没有加速的油门，也没有懂得这台发动机的机修工。” 负责系统运行维护的经理Neal Kelshaw这样形容Openworld面临的性能治理挑战。
  
    “要调整这样的订单系统，必须在容量资金限制与提供客户事务处理之间达到平衡，并且达到要求的吞吐量，” Kelshaw说，“这些因素通常会对系统设计提出一些相互冲突的要求，我们并不知道，体系结构如何为通用组件分配系统资源，也不知道系统会对接口负载作出怎样的反应。这些因素会对系统性能产生一些混合影响，使我们处于两难选择的境地。我们的目标是让所有组件协调运行。”
  
    我们的团队熟悉到，系统并没有达到最佳运行状态，客户订单经常不能在协议规定的交付时间执行，而且需要不断对系统进行人工调节，负责处理订单流程的人员还要负责不断的以手工方式，进行系统调优、打补丁和风险治理。“我们担心这会危及客户满足度和我们的收入，” Kelshaw接着说，“在这次价格调整前，订单量的变化幅度比现在要小。
  
    在价格调整后的六个月时间内，开发人员推出了超过60种补丁程序。每次发布产品或订单量发生变化时，都需要推出补丁。而且这些补丁也只能应对性地调节系统。我们不知道应该查看什么参数，也不知道它们如何交互作用，形成我们主动治理平台利用率和容量所需要的规则。而在这样一个支持英国电信要害计划的高销售量的环境中，这是支持订单治理系统的要害。假如拿汽车来打比方，我们无法达到最高速度，每次当我们要行驶更远的路程时，都必须把车开回车库，进行全面的故障检修。我们想知道的第一件事就是：客户对这个系统的体验如何，而不想查看大量的容量统计。这一工作完成后，我们得知平台的规模是适宜的。我们必须调节系统，以达到要求的吞吐量，这样会导致性能降低，客户无法使用注册流程。
  
    使用Mercury Topaz事物处理监控解决方案，我们确定了性能瓶颈问题，并且发现达到吞吐量对后端流程的影响。一项新技术向我们证实，我们关注的系统的规模是适宜的，我们的知识缺陷在于组件监控方面，我们不知道导致订单处理流程不可用的问题的真正根源。”
  
    在对所有的领先应用性能治理供给商进行严格审查后，英国电信互联网业务部门最终选择了VERITAS 软件公司。“VERITAS i3能够百分之百地满足FRI文档的需要，”他说，“我们在其他项目中使用VERITAS软件的成功经验，加上软件的易用性，以及它与我们的eHub体系结构和的无缝集成，使它成为我们的理想之选。”
  
    由于时间紧迫，英国电信直接将VERITAS i3应用到实际生产环境中，所有工作都在几小时内完成。一小时后，VERITAS i3能够全面概括出eHub系统的组件，并指出导致响应时间延长的一个组件。
  
    “在VERITAS i3完全投入使用的第一天，它就找出了问题的确切原因：设备数据库中存在一个Oracle性能问题，影响与远程数据库连接的Tuxedo联接。该问题影响了eHub的容错性能，导致订单排队的失败。我们及时解决了该问题，这应该归功于VERITAS i3。在此之前，我们只能看到前端出现的症状，而没有找到问题的真正根源。 ”
  
    使用VERITAS i3，英国电信现在能够预先检测、查找、关注、改进和校验性能问题，避免它影响服务水平。通过跟踪特定应用环境的要害性能指标，VERITAS i3简化了查找和修复性能问题的复杂流程。该软件还为英国电信提供了组件度量标准和计数器，用于主动评估和治理系统配置，在高容量的、不断变化的订单系统中维持服务质量。这些度量标准还可用于精确调节应用，加快事务处理和响应。这就使应用基础设施能以最高效率运行，并且意味着Kelshaw和他的团队可以降低故障成本、容量和支持成本，改进客户体验，而不再受到配置不当的基础设施的困扰。
  
    “VERITAS i3为BT Openworld带来了诸多好处，” Kelshaw说，“首先，最重要的是它可以缩短解决eHub性能问题的时间，我们估计英国电信每年可以节省50万英镑的支持成本和订单收入损失风险；其次，它使我们能够根据预期的订单量来调节系统，确定订单量对体系结构的影响。然后，我们就能够在发生任何故障之前，主动优先完成组件的更换和升级，并且有效地治理容量；再次，VERITAS i3加速了客户体验，确保了客户对BT品牌的忠诚度；第四，它为我们提供了强大的、精确的事件记录，可用于直接与外部供给商确认问题，并能有效地向上跟踪在其他地方发现的症状。据我所知，在现代的分布式J2EE基础设施中，还没有其他任何产品能够实现这一点。”
  
    让我们再次回到本文开始时的汽车类比，下次当英国电信的汽车速度减慢，VERITAS i3就能立即确定发动机的哪个部位出现了故障，确保配备机修工排除故障，维持发动机的完全功率。此外，VERITAS i3不断进行性能监测，可在性能缺陷出现前进行猜测，并在故障发生前立即进行修复。