|
绪言
企业级－”，这个定语前缀已经越来越频繁的出现在IT领域，它一旦同“网络”，“服务器”，“安全”，“应用”相结合，原有的这些名词马上变得身价倍增，无论是成本，规模还是被重视的程度，而一旦“开发”被赋予了这么一个前缀，原本是一个那么日常的工作一下子就被套上了神奇的光环。我们不妨定义一个专门的表示形式 “开发企业级”，来表示它于一般开发的区别。
那么，“开发企业级”到底同一般的开发行为有何不同呢？我们可以从以下几个角度进行分析。
1． 关键性。
显而易见，IT技术现已成为企业核心竞争力的一个重要组成部分，是业务成败的决定因素。信息技术通过不断的技术创新，一方面不断完善自身的体系结构和实施手段；另一方面，它引导新业务模式的产生，成为生产力提升和变革的原动力。正是由于信息技术对于企业经营模式，乃至整个社会沟通方式所产生的显著而巨大的影响，它已经从一个辅助性的角色，转变成为众人所瞩目的重点话题。多种类型的“应用”就是IT技术最终的实现形式。而对于特别复杂，特别重要，使用者特别多的应用，我们需要通过特殊的手段保证“应用企业级”的可靠性（Available）和性能（Performance），这是“开发企业级”的最终目标。
2． 可靠性
让我们把目光从整个社会的大范畴聚焦到一个企业，信息技术的发展已经到了一个极制。7×24的全天候访问，跨越软硬件平台的无限可扩展性，简单、一致的用户自助服务界面……诸如此类的苛刻要求，都是为了满足业务部门“更快、更高、更强”的高可靠性要求而制定的。这是一般应用和“应用企业级”之间一个巨大的区别，无论在设计、开发、测试还是部署阶段，“开发人员企业级”都要把精力投入到确保“应用企业级”的高可靠性上来。Server Clustering， HA，RMI等技术应运而生。
然而，在信息系统满足了上述的种种要求之后，其自身的结构也变得异常的复杂。下面的图示反应了“应用企业级”的基本技术构成元素和层次：
“应用企业级”好像一架天平，在可靠性这一段我们已经加上了重重的砝码，而另一端还有“性能”这个因素没有得到保证。
3． 性能
对于“应用企业级”的性能，传统的实现方法是通过专门的维护团队来保证的。对单一类型的应用而言，其“性能”是可以通过这种方式得到保证的。无论是数据库，还是应用服务器，乃至在更加复杂的定制应用和打包应用领域，都有厂商或者集成商的专业技术人员来为之提供支持服务。对于用户而言，无论是依靠厂商的服务，还是自己拥有的系统维护团队，对于单一类型的应用系统尚且能够确保性能。但随着特定技术之间的交叉、融合，只单纯掌握一种技能的人员，已经越来越难以应付系统性能所提出的挑战。
应用的复杂性在20世纪的最后十年，伴随着Web技术成为数据展现和操作访问的事实标准，企业利用这个平台，将原来分散的子系统进行着整合，原来单一类型的应用系统已经成为企业应用系统的一个组成部分。在一个典型的企业应用环境中，从后台的硬件存储开始，往往要通过数据库、应用服务器、Web服务器和客户端应用几个技术层次来实现业务操作，其中还会由若干承担具体任务的中间件产品和技术扩展，来提供诸如均衡负载、高可用性、可伸缩性等企业计算所必须具备的功能。
基于Web的应用，已经显著改变了服务的基本经济原则、竞争力和用户界面。Web应用迅速代替成本更高的“人员协助”传统服务。这种新一代应用为企业提供了独一无二的机会，使之能够利用传统系统，在多个服务“层”之间分配应用，充分利用新计算技术的优势。虽然这些基于Web的应用为公司提供了无与伦比的灵活性，但更加复杂的应用却使所在的基础设施面临不断的改变和超高的负载，应用性能的下降所导致的不良用户体验，反而降低了客户的满意率和忠诚度。
当今的用户都期望能在世界各地随时访问网站。如果应用的用户发现屏幕底部的蓝色进度条从左到右前行的速度过慢，他们就会离开该网站，而且通常不会再次访问。同样，如果服务水平没有达到期望值，现有客户端通常会重新使用陈旧的、高成本的旧用应用来处理业务，或者开始关注其他供应商或服务。从而使企业的管理者认识到，由于目前业务对于信息系统的依赖性，如果不能遏制应用性能下降导致的客户流失，如果不能克服复杂性所导致的迟缓的故障排查，对于新技术的使用以及系统的整合都会适得其反，反而会导致业务的下滑。
如何确保“应用企业级”性能的要求，已经成为在可靠性之外，对于系统得管理和运行维护人员提出的一个更高的挑战，对于原先只关心“应用企业级”的准确性和可靠性的开发团队而言，保证“性能”成为应用生命周期的最后一个链条，谁能够将其稳妥的完成，谁就完成了“开发企业级”的整个闭环。
为了提高“应用企业级”的性能，最直接的方式就是对硬件进行升级。不可否认，它直接导致了硬件性能的快速增长和硬件价格的迅速下滑，然而，再现在这样一个投资紧缩的年代，精打细算的IT管理人员已经在“应用企业级”的更深层次寻求改善性能的方法。
首先，如何在众多的技术层次之间定位和隔离问题？
多层次系统模型的优势是具有更强的可扩展性，可以无限制增加的处理能力以及灵活的部署形式使之在企业级系统领域具有旺盛的生命力；然而，系统的复杂性也伴随技术层次的增加而迅速增长。相比较原有的单一技术构造的应用而言，在出现了性能问题之后，如何将其定位到某个技术层次上，是解决问题关键的第一步。但是，由于缺乏统一的性能衡量指标，这第一步却往往很难迈出。
其次，如果在缺乏可视性的情况下找到根本性问题？
以J2EE方式构建的系统为例，客户往往能够将性能问题定位到某个用户调用，然而，在这个方法调用以下，可能会隐藏着几层甚至十几层的系统调用，这对于用户是不可见的。对处于Java应用和操作系统之间的JVM而言，用户就更加难以对其进行调整，原因同样是缺乏可视性。
第三，如何解决问题？
对于单一的技术组成部分，例如数据库、中间件或者应用服务器而言，专门的技术人员能够解决相当数量的性能问题，然而由于技术的迅速发展和演化，以及更多种类的技术同时出现在一个应用系统中，对于技术“全才”和快速学习型人才的要求愈发迫切。为了达到这个要求，更多的费用会产生在技术培训、人才雇佣等诸多环节。如果能够有一个软件，将每个门类技术专家的技能都集中起来，供大家分享，这无疑是一个经济高效的解决方案。
第四，如何对问题进行校验？
多层次系统模型的复杂性不仅增加了定位问题的难度，在如何确保问题的解决方法正确性和高效性方面也提出了挑战。在此类系统中很有可能出现，对一个性能问题的调整导致更多性能问题出现的情况。而且，在生产环境中，性能的调整将是非常慎重的，在对改进方案没有100％的把握的情况下，是不可能投入实际生产的。所以，我们需要对改进方式，在生产环境之外进行校验。而这种环境又不能同生产环境所产生的真实数据完全脱离。
第五，是否有一种方法，能够确保应用性能持续的高水平？
在生产环境和开发环境中进行应用性能调整的一个显著区别是，前者非常关注调整的效率，也就是从发现问题到改正问题之间的时间越短越好。如果能够做到在应用问题影响到用户体验之前就进行修正，从而提供一个持续保持高效运转的应用系统，将是每一个系统维护人员的最终目标。
APM的方法论和解决方案
在这种情况下，一种对于应用性能进行监控、报告、分析、改进以及趋势预测的技术应运而生，我们把这类技术成为应用性能管理（Application Performance Management）。我们可以这样来定义APM：“是在实际生产运行环境中，从应用的角度对系统性能进行监控、分析和优化的管理方案”，它不同于以往针对某种技术层次的调优工具，具有以下几个鲜明的技术特色：
1． APM着眼的是应用系统整体的性能管理，而非仅仅针对某个技术层次的“烟囱式”的解决方案。
这是一个典型Web应用的用户访问路径，通过一系列的“访问”，用户能够最终实现一个完整的交易过程。在每个“访问”的过程中，APM都能够以该“访问”所花费的时间，占最终用户总的响应时间所占的比例为主要的衡量标准，也就是通过比较各个技术层次对客户响应时间所做出的“贡献”，在第一时间将问题定位于某个技术层次。
此外，APM具有从一个技术层次到另外一个技术层次透明过渡的能力。也就是说，如果在J2EE层发现性能下降是由于一个JDBC访问引起的，那么APM能够从该方法的调用反向生成SQL语句，从J2EE应用的性能管理过渡到对数据库层次的性能管理工具，最终通过修改某个数据库表的索引而解决性能问题。并且，在修改问题之后，APM也会从应用整体响应时间的角度，将性能的变化对于整个系统的影响显示出来，而不仅仅限于数据库层或者J2EE层。
2． APM的视野不仅足够宽广，而且足够深入。
APM拥有钻取的能力，能够对表层的性能问题，通过层层拨茧的方式，按照访问的路径深入下去，直到搜索到问题的根源为止。这对于在缺乏可视性的应用中进行性能管理，例如EJB调用，是非常关键的。此外，APM还必须在发现问题之后，具有修改问题的能力。对于数据库应用而言，APM能够提出建议来帮助用户修改性能不佳的SQL语句，或者调整数据库对象的属性；对于具有成百上千个参数的J2EE应用服务器来说，APM能够在发现问题之后，向用户提供建议如何调整参数而达到最优性能。
3． APM考察应用系统的性能依据，来自于用户的真实操作数据。
同比传统性能调优工具使用的模拟数据，APM进行性能调整的依据是用户实际操作的数据，将用户体验、使用习惯、业务波动和技术指标综合考虑。显而易见，这种数据只能来自于生产环境。传统的性能调优工具之所以大多只用于开发环境，是因为其过高的系统负载，而APM产品依靠其对于应用超低的负载，能够实施7×24的对于生产系统的长期监控。
4． APM拥有专门的数据存储。
APM将采集的数据经分析之后存放起来，而不是在考察之后就抛弃，或者仅仅保留短时间的性能数据。只有这样，使用者才能够通过对于长时间的历史记录的分析得到结论，从而了解：过去曾经发生过什么，现在正在发生什么，以及今后即将发生什么。这就使得，APM不仅仅是一个在性能问题出现后进行补救的工具，而且能够为系统的维护团队提供预警信息，在性能问题真正开始影响用户的使用之前，就将其改正，保证为用户提供一个性能可靠，坚如磐石的应用系统。
未来的发展方向
从单纯面向某个技术环节的性能调优工具过渡到APM，是一个技术不断发展，不断整合的过程。在原先只提供单纯性能调优工具的厂商中，纷纷提供向相邻技术层次组件进行关联分析和性能管理的扩展。而对于APM本身，它的发展目标也是要将更多的技术层次纳入已经形成的技术架构之中。例如：在目前的APM产品和解决方案中，所监控的技术层次主要是应用服务器，数据库，Web服务器，而对于目前快速增长的企业应用整合（Enterprise Application Integration）市场，APM除了能够覆盖以上的技术组件之外，对于EAI应用中处于核心地位的消息中间件也要具备监控和管理的能力。向这个市场上的代表性厂家的产品，如Webmethds，Tibco，MQ Series的扩展，将是APM产品的下一个技术发展方向。
其次，APM也将触角伸向整个技术堆栈的最底层，存储层。目前，APM能够通过对于有限的存储硬件的支持，提供对客户调用路径的完整监控，如何通过存储虚拟化软件来实现对于最广泛的异构存储设备的支持，将是APM在这个领域发展的下一个目标。
第三，用于将各个独立的工具，或功能组件，进行统一管理的性能控制面板，也是各家一致的发展方向。今后的APM产品将基于统一的架构，提供统一的安装和使用界面，在这方面无疑Web是最优的一个选择。处理各个技术组件的性能管理工具，将作为插件存在。
第四，能够跟踪任一用户交易全过程，提供统一的性能衡量指标的性能管理产品将代替单一的性能调优产品。
第五，APM产品将兼顾“应用企业级”的“可靠性”和“性能”两个方面，覆盖“开发企业级”的整个生命周期。实现对“应用企业级”从设计、开发、运行，直到升级的一个完整闭环。
在IT的世界从来就是开放系统和专有系统的交战，无论在硬件，操作系统还是各种应用系统中，在APM的领域也是如此。APM覆盖的各个技术层次的厂商也大多提供对于自己产品的调优工具。同时他们也明白，对于单一产品的监控和管理，对于当今的复杂应用环境而言会逐渐走入一个封闭的市场，所以，这些厂商也会在一个更加广泛的领域中管理其产品的性能。APM厂商的优势是广泛的产品覆盖，而组件厂商的优势是对于自身产品的透彻了解，究竟谁是最后的胜者，我们也将拭目以待。
案例
两年前，英国某电信公司的互联网业务部门开发了一款全新的尖端网络中心系统，用以提高ISP的性能和可用性，改进客户体验。这款网络中心系统基于分布式J2EE体系结构，使用BEA Weblogic应用服务器和中间件Tuxedo，系统使用Oracel数据库，横跨多台Sun Unix服务器，并连接到远程数据库和订单处理系统，以进行客户管理和宽带设置，这无疑是一个复杂的多层次计算环境。
该系统的运行维护人员意识到，要调整这样的系统，必须在容量和资金的限制与提供客户事务处理之间达到平衡，并且达到要求的吞吐量，而这些因素通常会对系统设计提出一些相互冲突的要求。他们并不知道，体系结构如何为通用组件分配系统资源，也不知道系统会对负载作出怎样的反应。这些因素会对系统性能产生一些综合影响，管理人员的目标是让所有组件协调运行。
在系统的性能下降之后，维护人员大多通过对系统打补丁的方式来调整某个技术组件的性能，但是往往在试验环境下运行良好的系统，投入实际的生产环境之后不能达到设计的标准；反之，在生产环境中发现的问题，也难以在开发环境中得到复制。
随后，该电信公司使用了APM产品来监控系统和发现问题。他们被APM的效率惊呆了，在APM产品完全投入使用的第一天，它就找出了问题的确切原因：数据库中存在一个Oracle性能问题，影响与远程数据库连接的Tuxedo联接。该问题影响了eHub的容错性能，导致订单排队的失败。然而，在此之前，他们只能看到前端出现的症状，而没有找到问题的真正根源。
使用APM产品，客户现在能够预先检测、查找、聚焦、改进和校验性能问题，避免它影响最终客户的服务水平。该软件还提供了组件度量标准和计数器，用于主动评估和管理系统配置，在高容量的、不断变化的订单系统中维持服务质量。这些度量标准还可用于精确调节应用，加快事务处理和响应，使应用基础设施能以最高效率运行，延缓了升级和继续投资的频率，在降低维护成本的情况下，反而提高了系统的整体运行效率。
总结
无论从知名度还是成熟程度来讲，APM软件还处于其成长期，它的前身是各个不同种类的性能调优产品，而它的未来必将走向融合和统一，并且出现公认的，对于IT系统的评价标准，这个标准将来自于，也只会来自于业务的需求和最终客户的体验。技术的汇聚（Convergence）是IT的发展方向，这一特性在APM领域也不例外。
在下面一篇文章中，我们将介绍在APM领域的主流厂商和技术，以及客户在采购该类产品中需要注意的问题。
作者简介：
吴启新 维尔软件公司产品市场经理
电子邮件地址： qixin.wu@veritas.com
|
