【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服务器监控机制的视野当中。
随着网站自身对于动态内容及第三方服务依赖性的持续提升，终端用户的实际使用体验往往只能依靠浏览器自身加以衡量。
