【IT168 技术】摘要：企业越来越依赖客户的社交渠道反馈，网站应用的一定要功能强大、反应速度快!许多Web 2.0解决方案可以提高Web App的速度和效率，但是同时也给传统的应用程序性能监控(APM)解决方案提出了挑战。大部分的监测方案都是部署在Web应用终端的浏览器，或通过数据中心部署第三方服务器，这两种方案还是有很大的技术盲点。由于此类活动通常不会产生指向企业网络的回调操作，因此我们有必要同时对边缘活动加以监控——从浏览器自身到足以囊括应用程序性能表现的全局视点。

　　本文针对当下市面上存在的监控技术问题给出的四大优化意见，旨在帮助Web 2.0开发者有效利用APM解决方案解决上述难题的。

　　随着Web应用程序速度与效率快速增长，网站已经成为企业与其客户进行交互的第一途径——某些情况下甚至成为惟一途径。在线电子商务网站的爆炸式发展就是这种情况的集中体现。

　　根据Forrester研究公司最新发布的报告，美国国内在线零售业务总销量至2017年将达到3700亿美元——相当于在未来几年内美国在线零售业年度复合增长率都将保持10%以上。为了保持自身竞争力，经营实体店铺的零售商们被迫将其关注重点转向在线销售渠道，从而避免成为Amazon.com及其它电子商务网站的免费展示设施。当然，这股风潮的涉及范围远不止于零售行业。

　　网站能够以成本更低的解决方案为客户带来产品与服务，此类机制与在物理位置提供现场服务的传统机制相比显然更具成本效益。

　　IT消费化趋势同样对网络经济体系的发展起到了推波助澜的作用。消费者希望能够在任意所处位置、通过任意设备访问更多服务。根据Flurry Analytics公司的调查，智能设备的普及速度比上世纪八十年代的PC革命快了十倍还不止，即使是上世纪九十年代的互联网风潮与近年才出现的社交网络覆盖在速度方面也分别只达到其二分之一与三分之一。

　　有鉴于此，在线体验——以及对网站在速度与功能多样性所提出的要求——已经成为关键甚至是核心。一系列趋势性特征已经在Web应用程序的设计当中显现出来，通常借由Web 2.0技术实现、例如JavaScript与AJAX，其中包括：

　　·降低页面加载数量。很多电子商务网站会通过减少用户浏览与结账所需要的页面数量来简化整个购买流程。举例来说，消费者在填写计算机配置单的过程中，完全可以在无需重新加载整个页面的前提下变更自己的选项、从而快速搭配出能够满足需求的组装机方案。

　　·异步页面加载机制。通常情况下，我们所使用的大多是HTML页面，这种方式能够大大提高网页的性能表现。具体来说，系统会首先加载体积较为小巧的HTML代码，而后以异步方式逐步加载其它体积更庞大的元素。举个例子，主页面会快速加载完成、全部信息与功能都以异步方式率先交付给用户。在此之后，宣传广告以及内容区信息(通常在操作后才需要显示)才逐步载入完成，并异步显示在我们眼前。

　　·纯客户端处理。现在对页面中各事件的渲染已经可以在完全不必与后端服务器产生交互的前提下完成。在这种情况下，对应内容由Web服务器作为页面的组成部分加以交付，但并不会直接予以显示——除非大家在操作中触发了相应事件。举例为说，当用户将鼠标悬停在某个下拉菜单上时，对应选项才会显示出来。

　　·内容分发网络(简称CDN)。通常情况下，来自浏览器的HTTP请求会由CDN或者其它缓存技术负责填写，这就避免了时刻触及后端Web服务器所带来的性能折扣。这种处理方式旨在为图片等静态内容提供更为出色的访问速度表现。举例来说，Akamai(网络存取加速服务)会在Akamai边缘处对全部页面进行缓存处理。

　　·调用第三方服务供应商的解决方案。另一类常见情况是，由浏览器生成的调用会直接指向第三方服务供应商，因此根本不会触及到相应Web服务器。此类实例包括嵌入式社交媒体插件以及用于提供位置信息的谷歌地图工具。

　　? 单页面应用程序。这是一类新近兴起的异步式交互机制，其中整套应用程序都被容纳在单一页面内部、而且其使用体验与桌面应用非常相似。该页面的加载过程由一系列异步式调用组成，而且完全由用户的操作实现触发。此类解决方案彻底摆脱了根据所需内容向服务器发送单一调用的传统机制，从而显著提高了性能表现并降低网络负载。Gmail就是此类方案中的杰出代表。

　　尽管优势明显，但Web 2.0却也给APM领域带来了不少挑战。在Web 2.0诞生之前，大家只需要对HTTP页面请求及其相关响应加以监控即可轻松追踪用户活动。在那个时候，Web服务器会将返回内容以完整页面的形式响应到用户浏览器当中。有鉴于此，监控机制只需要关注高级页面中的独立请求，也就是说整体与单一请求性能表现都可在HTTP请求层面实现监控。由于所有请求都会被发回到Web服务器，我们只需通过Web服务器层中的代理机制或者对通过线缆传输的数据包进行采样即可有效完成监控任务。这也是APM解决方案早期曾经采用过的常见处理方式。

　　在Web 2.0时代，各类浏览器都拥有了在单一网页内部执行嵌入代码的能力，这就消除了代码执行需要调用后端应用程序服务器的必要需求。JavaScript是目前在此类应用领域中普及程度最高的语言选项，凭借着自身在速度、效率以及降低网络负载方面的优势(通过运行在终端用户本地硬件之上实现)、它甚至在全部主流编程语言中也保持着旺盛的人气。JavaScript的适用范围极广，其中包括处理页面动画元素、播放音频与视频以及验证Web输入数据等等。

　　AJAX(即异步式JavaScript与XML)编程趋势的普及则进一步拓展了浏览器在处理异步式请求方面的能力，进而使其能够仅对页面中的特定部分加以更新、而不再需要重新加载整套页面。举例来说，用户在处理结账页面以及运费请求时，他或者她完全可以在与专家沟通后直接查看价格变化而无需重新载入整套页面。

　　AJAX与JavaScript强大无比，但也给利用传统方法监控Web应用的管理人员带来了一系列挑战。

　　下面来看其中一些与上述方法相关的主要盲点，包括：代码级分析缺乏，传统角度讲APM解决方案专注于通过在数据中心服务器内安装代理机制以实现对代码执行情况的监控。但现在这类方案只能反响一部分实际情况。

　　在现代Web应用程序当中，约有八成的代码执行在浏览器内部完成。应用程序服务器内的字节码也存在类似的情况，换言之，必须将测试工具转向浏览器端才能有效监控JavaScript执行与错误状态。

　　不正确的页面响应时间。时至今日，单纯监控网络流量本身已经无法准确衡量页面的实际响应时间。利用这种方式，只有每一个独立对象(或者点击)所引发的HTTP请求与响应才会返回到Web服务器(或者原点)处、并接受时间检查。然而在Web 2.0时代，很多请求根本不会返回到原点，而更多地被路由至CDN或者利用缓存技术被填充在其它环境当中。

　　我们同样无法利用网络采样方式处理指向第三方Web服务(例如谷歌地图工具)的调用操作。为了对广告、地图、购物车、网络分析、社交媒体模块、CDN与DNS响应时间等进行全面调查，必须通过身处浏览器内部的监控方案对页面载入时间加以审查才有可能实现。

　　背景信息不足

　　在理想条件下，网络流量监控能够将后端调用与将其发出的页面关联起来。对于传统应用程序而言，由此带来的背景信息已经足以用于进行故障排查，但在AJAX领域却无法顺利起效。在AJAX环境下，单一页面发出的调用可能成百上千。而更具挑战的是，大量JavaScript事件(例如鼠标点击菜单选项)根本不会创建出指向Web服务器的调用，这就让此类纯浏览器事件消失在了网络采样方案与Web服务器监控机制的视野当中。

　　随着网站自身对于动态内容及第三方服务依赖性的持续提升，终端用户的实际使用体验往往只能依靠浏览器自身加以衡量。

　　四种方式让你的APM战略步入现代化轨道

　　随着一系列新兴技术成果的出现，Web 2.0在带来挑战的同时也蕴藏着巨大机遇。尽管传统方法已经不能单凭自身力量完成任务，但将令人振奋的新兴检测技术作为补充、进而与原有方案相结合则能够提供远超以往水平的洞察能力。下面我们就来介绍四种足以应对Web 2.0新时期下新型难题的APM战略升级思路。

　　1. 捕捉功能性问题并建立背景信息

　　在处理面向外部的应用程序时，性能表现并不是惟一需要关注的重点。应用程序的功能性问题在出现频率上要远高于性能问题，这同时也是导致用户放弃甚至转而使用其它站点的首要原因。由于Web应用程序通常扮演着企业与其客户进行交互的惟一渠道，因此故障排查人员往往不太可能亲自与用户进行沟通以了解到底是哪些环节出了问题。

　　试想一下，假设由于应用程序的设计存在缺陷、其在处理开头为零的邮政编码信息时出现了错误。

　　在这种情况下，采用能够捕捉浏览器事件的解决方案，例如鼠标点击以及键盘输入数据，显然能够重现用户的会话活动、从而帮助我们主动识别并解决这些问题。

　　2. 捕捉JavaScript错误并对其进行故障排查

　　考虑这样的场景，如果某家企业希望推出一项全新AJAX功能以实现网上下单操作、但却不断返回JavaScript错误，结果会怎样。这一切在Web日志当中可能根本没有体现，而且所有响应时间看起来都极为正常。结果呢，故障排查人员甚至根本感受不到问题的存在——直到客户们的抱怨之声铺天盖地而来。在这种情况下，糊涂不再是福、而意味着潜在营收的大量外流。

　　我们的APM解决方案应该能够检测JavaScript错误并就此发出警告，从而敦促技术人员尽快着手加以处理。

　　3. 关注来自页面加载时间的细节信息

　　为了将广告、地图、购物车、网络分析、社交媒体模块、CDN与DNS响应时间等因素确切纳入监控范畴，我们必须在浏览器内部对页面加载时间进行高度关注。幸运的是，现在新一代IE、火狐以及Chrome浏览器都已经提供HTML 5导航定时功能。它能够将完整的页面加载时长拆分成DNS查找、重新定向、SSL握手、处理以及缓存访问时长等具体项目。务必选择一套具备此类功能的APM解决方案。

　　4. 将问题隔离在特定页面元素当中

　　目前浏览器所能捕捉的信息还仅限于完整页面加载内容，也就是说无法针对个别页面提供定时信息，例如载入图像或者图片、CSS样式表、指向Web服务器或者REST API的后端调用所用去的时间。具备网页分析功能的网络采样工具则可以为指向单独页面对象的HTTP请求与响应计时，从而帮助故障排查人员将问题固定在特定页面元素身上。在选择网络监控解决方案时，请大家务必确保自己采购的产品具备这项功能。

　　APM对Web 2.0应用程序实施监控原理

　　好的APM产品要以客户为中心、且能够与APM相协作的解决方案，能够在数据之外为IT以及业务部门带来更为确切的答案。除此之外，大家可以选择将其与数据库、虚拟化或者网络性能监控机制结合起来，从而进一步发挥APM在整体企业监控战略当中的全能实力。

　　结合传统与现代解决方案中的诸多优势要素，APM产品应该具备如下卓越特性：

　　·能够捕捉每位用户的每一次点击并重现Web用户的实际活动，从而真正复制用户使用体验、从而实现背景信息取证并完成故障排查。

　　·利用强大的应用程序运行时架构自动发现机制将我们的应用程序与基础设施关联性加以映射。

　　·确保精确的问题区域识别、详尽的响应时间分解以及完整的传输路径可视化呈现——从应用程序层到终端用户，整个流程尽在掌握。

　　·将所有用户以及追溯信息容纳在一套以“事务”为核心的通用型框架当中——从而保证数据与工作流程以无缝化方式进行协作，并提供少有的可视化显示效果。

　　·弥合虚拟化与共享资源冲突给Web应用程序带来的影响，保证数据与关系在所有事务维度中的和谐统一——从浏览器到数据库、从代码层到虚拟机管理程序。

　　·利用细致的根本原因分析机制，在Java与.NET应用程序服务器内部揪出代码层瓶颈。

　　·追踪每项请求的调用堆栈并捕捉相关支持证据，包括内存(堆)统计、方法参数以及SQL绑定变量等。

　　·利用丰富的监控数据与高可扩展性分析机制提供开箱即用的分析与可视化处理方案。

　　听云：中国非常好的APM解决方案提供商

　　听云能够捕捉规模庞大的性能表现与内容数据，从而在Web 2.0应用程序中准确识别应用程序性能与功能问题。具体包括：

　　·背景信息取证，用于了解用户在执行何种操作时遭遇问题。

　　·捕捉来自整个会话背景的键盘/鼠标事件。

　　·检查AJAX事件以识别错误与性能表现。

　　·比如中国领先的APM产品听云对页面对象的HTTP请求与响应计时有着严格跟踪。检查并识别各类功能性问题。

　　·精确反映页面响应时间及具体的导航计时结果。

　　·昼夜不停地对可用性及性能表现进行测试，包括无用户活动的时期。

　　·能够对JavaScript性能表现与错误进行故障排查。

　　·能够将问题隔离在特定单一页面元素当中。

　　·能够根据需求在浏览器内部对监控细节级别进行配置。

　　总结

　　以JavaScript与AJAX为代表的Web 2.0技术体系为Web应用程序带来了优势显著的处理速度提升，同时也让性能表现与执行效率迈上新的台阶。不过Web 2.0同时也给传统应用程序性能监控方案带来了诸多挑战，希望APM产品能够为开发者给予帮助。

　　国内APM领导者听云帮助软件开发团队和运维团队得以将自身应用程序性能监控战略推向现代化层面，并在浏览器内部充分支持AJAX处理机制。除此之外，这款产品也是目前惟一一款能够将传统与现代方案的各项优势加以结合的卓越APM解决方案。