基于Java平台的Web应用系统业务性能监测

李杰 张攀翔

摘 要随着日益激增的IT应用复杂性，企业同时面临业务需求更快的变化，用户期望持续攀升，需要更高的性价比等方面的影响，在这些因素的影响下，IT应用在运行过程中发生诸如性能下降或者服务不可用等故障的可能性大大增加，从而影响业务服务的正常运行。业务部门渴望更加清晰、实时的得到关键业务应用的分析数据，来把握用户行为，影响分析和转化率。

【关键词】用户体验 业务性能 监测分析

长期以来企业IT运维停留在“以资源为中心”的管理模式，关注的是IT资源的可用性和相关技术性能指标，对IT用户行为和业务性能（体验状况）却是一无所知。例如用户来自哪里，做了什么操作，遇到哪些错误，业务处理消耗多少时间，业务性能耗时在网络，还是服务器（程序逻辑及SQL 逻辑）…等，所以这些用户体验显得尤为重要。因此有效地管理这些应用，提升用户体验，需要在系统性能、使用效能、可用性监测等多个方面进行保障与提升，是业务发展的迫切需要。

1 现有技术方案及缺点

1.1 现有技术方案

对于大型的应用系统，业务功能模块至少几十个，每一个功能模块根据业务实际情况，性能呈现存在差异，如何有效对业务模块性能进行自动化监测与分析管理，了解真实用户体验，对用户体验不好业务缺乏问题精定位與分析，主要分如下三种方式来执行：

1.1.1 用户报障方式

依赖于用户报障，如用户在使用某项功能或执行某项操作响应变慢，执行时间较正常时超出许多。由用户报障给业务维护部门，维护人员通知开发人员及数据库人员对性能问题业务进行跟进处理。

1.1.2 日志记录方式

在应用系统设计、开发阶段，或者是在新增业务正式上线前，设计人员、开发人员等凭借设定好的标准日志格式，记录对业务功能点每一个步骤耗时，通过日志记录方式监测与分析业务处理性能；在系统正式运行过程中，当发现业务功能较慢时，通过人工分析日志方式被动分析业务性能较差的原因，优点可获取用户真实体验数据。

1.1.3 主动模拟方式

主动模拟是通过定期执行预定义脚本模拟用户访问应用系统来获取事务可用性和响应时间，一般需要在靠近用户端位置部署主动模拟装置，优点是能够7×24小时持续不间断地对应用进行监控和能够早于用户发现问题， 维护人员凭借个人经验手工分析业务每一个步骤耗时情况，如判定业务逻辑设计不合理，导致性能较差，通知开发人员修改业务逻辑及后台SQL；

1.2 现有技术的缺点及该文要解决的问题

现有技术有如下缺点：

（1）通过用户报障，这时业务已经受到影响，是个别用户性能问题，还是普遍性较差，无法统一进行判断，这时业务性能分析是采取被动方式进行端到端分析过程，往往问题真正得到解决需要花费大量时间，对业务造成不可估量的影响。

（2）日志记录方式，虽然能够很好记录系统业务功能每个步骤性能情况，但取决于系统设计之初有良好日志记录方式，如果没有相应标准日志记录方式，则需要花费大量人力及财力，对系统进行改造，效果并不理想。

（3）主动模拟方式，现实中常常只用于对关键业务性能进行探测分析，如果覆盖全业务功能，大规模探测会干扰系统整体性能，并且获取的不是真实用户体验数据缺乏业务分析价值。

（4）当系统业务整体性能出现缓慢现象时，数据库人员、开发人员、中间件人员各自所负责技术进行性能排查，属于大海捞针的做法，需要花费大量人力物力去定位与分析，缺乏有效手断去定位是哪一个请求及后台SQL存在性能问题影响到业务整体性能情况，所于事后排查，效果并不明显。

现有技术方案虽然有事前及事后两种应急处理方式，都存在缺陷，无法精准对业务性能进行监测（真实用户体验信息），业务性能定位与分析需要花费大量人力、时间来进行处理，存在一定的被动性及肓目性。目前大量的运维实践经验表明，即使在后端资源监控比较完善的情况下，仍有相当多比例的问题依然是由用户首先发现和报告的，不仅降低用户的满意度，也使IT运维工作相当被动，因此有必要寻找一种合适技术手段对业务性能进行直接监控，以弥补现有IT资源监控工具的不足和缺陷，帮助企业全面掌握IT终端用户的行为和体验状况，促进IT运维面向业务和面向用户体验。本提案主要针对真实用户体验数据进行采集、业务性能告警、业务性能分析三部份进行详细介绍，阐述如何主动对用户真实体验数据进行采集，对业务性能进行提前预警，性能分析快速定位业务逻辑及sql问题，大大的提升存在性能问题业务处理效率。

2 基于Java平台的Web应用系统业务性能监测及分析的实现

本方案主要分为三层来实现，如图1所示。

2.1 采集层

此模块负责对系统整体及关键业务的相关性能数据进行实时采集，针对大型业务系统，业务本身访问比较繁忙，频繁采集所有业务模块性能数据，势必干扰业务正常使用，可以利用网络旁路侦听技术进行采集可很好解决此类问题。

网络旁路侦听技术主要是通过SPAN模式（交换机端口镜像）或TAP模式（网络分流器复制）将需监控应用系统网络流量（包括上行和下行流量）接入专门负责报文解析的旁路侦听设备中，具体部署方式如图2所示。

（1）在连接应用服务器交换机，将应用服务器端口进行镜像到另外一个端口

（2）将镜像的端口与旁路侦听设备服务器连接，无侵入式，无需安装探针、代理，全面保障整个业务系统正常运行。

（3）系统将自动收集交换机的所有报文信息，并将信息入库到系统数据库。

（4）报文信息将包括用户访问rul地址，用户session信息，网络传送时间等信息。

我们知道，在基于B/S架构应用中，当用户访问应用时，用户请求会通过网路传递给WEB服务器，然后WEB服务器对用户请求进行处理，并将处理结果返回给客户端。如图3所示。

通过网络旁路侦听技术可以方便捕获用户与WEB服务器之间的交互报文来分析用户体验行为，并且能清楚了解用户与WEB服务器每个交互的细节。例如用户访问了应用的那个功能、cookie/session-id、GET/POST参数、客户端IP、服务器IP、访问量、浏览器类型、服务器响应码、服务器响应时间、网络传输时间等等。通过对这些数据进行多维度分析，就能提供获取应用的用户体验情况和各种有价值的多维度分析报表，除了对IT运维有分析价值外还能进一步挖掘业务价值。

2.2 告警层

通过对业务指标告警的定义及告警阀值的定义，发现有超过阀值KPI指标的业务，进行异常情况告警，例如某某业务平均响应时间大于N 秒时产生告警事件，同时支持告警关联及告警指标自定义建模，支持自定义告警。

性能预警规则级别定义参考如表1。

2.3 分析层

2.3.1 业务分析角度

关键性能指标 （KPI） 是用于测定系统性能优劣的可计量度量值，经常会在一段时间内评估 KPI。这点非常重要，如果性能的好坏单纯依靠用户的感官，就会使优化工作陷入泥潭。可量化的、可参照的优化指标是优化成果得到认可的重要度量，也是性能优化的源动力。那么如何制定得到各方认可的性能KPI，可通过行业特定领域里广泛认同的最佳实践，制定一系列用户体验有关的KPI维度，主要包括效率、效益和整体满意度和服务质量预期的对比，来评估Web系统性能：

（1）系统监测维度。应用性能杀手排名、最慢的页面排名、系统资源开销排名、 实时系统性能分析、应用大对象监控、中间件及数据库性能监测等。

（2）地市运营维度。实时系统整体满意度、地市整体满意度、实时系统整体出错率、用户访问区域分布、发生错误的页面错误分类及比例、客户满意度实时趋势分析、用户行为分析。

（3）用户感知维度。业务响应时间、接口处理时间、业务稳定性、业务可操作性等。根据开发语言、业务类型不同及上面三个监测维度监测实际业务性能情况，可定義很多种性能指标。业内通常以2/5/8作为性能好坏的分界点，2秒以下为优秀，2-5秒为良好，5-8秒为可接受，8秒以上不可容忍。

2.3.2 代码分析角度

前面提到使用网络旁路侦听技术，主要是对业务性能监测，能与业务行为紧密结合在一起，但不能真正的进行故障分析和定位，不能实现代码级分析，而利用java平台JVM虚拟机（agent）代理技术实现。通过java agent技术就可以不用修改原有的应用程序代码情况下，实现包括代码级别性能问题的可见性（事务 Traces 记录）、性能瓶颈的快速识别与追溯（业务代码涉及函数或方法的响应时间、SQL语句耗时）、服务器性能监控（线程 Profiler）和端到端的应用性能管理。

2.3.3 分层分域，闭环优化角度

如图4所示，优化包括服务器端的多个部分，如主机、存储、操作系统、中间件、代码、数据库、sql等。问题可能存在于多个方面，优化人员应当如何入手呢？以用户感知为导向，用户只需指出哪里有问题，采用分层分域的优化手段及闭环优化流程，提高优化效果与优化效率。

分层：即纵向对应用系统的组成部分分层，通常我们将其分为硬件层、平台层与应用层，首先判断问题发生在那里层面，再由不同专业的工程师进行分析处理，该做法可充分利用工程师的专业能力，提高优化质量。

分域：即横向对用户提出的问题按优化级别进行分类，哪一些是重点问题域、重要场景域、共性问题域，对一些相同类型的问题分析处理方法大同小异，利用已有的优化经验可加快问题处理效率。

闭环优化，主要是对用户提出的每一个优化点实施可控制的闭环优化流程，性能KPI 贯穿整过过程，优化成果经得起推敲。如图5所示。

（1）性能评估：用户在标准用户终端进行应用操作，性能优化人员进行性能评估，重现、定位、分析性能瓶颈，对收集的性能问题进行分析过滤，对于在对应KPI指标外的问题进行统一优化分析及处理。

（2）方案制定：性能优化人员对性能问题按分层分域进行分析后，制定相应的优化方案，并组织业务专家、架构专家、开发团队进行多方评审。

（3）方案测试：经各方评审后的优化方案，即可在测试环境实施，并验证评估优化效果和影响。

（4）优化实施：方案测试通过后，根据版本部署计划在正式环境上线实施，并做好应急保障。

（5）优化验证：通过标准用户终端进行应用优化效果验证，并组织业务专家、性能问题上报人员进行验收。

（6）规范总结： 优化完成后，输出经验与规范总结文档，指导架构设计和开发。

3 总结

综上所述，对系统产品而言，速度是用户体验产品的第一感知，是系统性能的体现，其中围绕监测、标准、优化三个核心进行可持续化的系统应用性能管理方法非常实用，目前性能管理也逐渐体系化和平台化。

参考文献

[1]唐文.海量运维、运营规划指导[M].北京：电子工业出版社，2014.

[1]唐文.大型网站性能监测、分析与优化[M]. 北京：电子工业出版社，2016.

作者单位

中国移动通信集团广东有限公司 广东省广州市 510623