APM最佳實務：Web 2.0和AJAX四大最佳化戰略

標籤：ajax   apm   web 2.0   

本文針對當下市面上存在的監控技術問題給出的四點四大最佳化意見，旨在協助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伺服器。此類執行個體包括嵌入式社交媒體外掛程式以及用於提供位置資訊的Google地圖工具。

 單頁面應用程式。這是一類新近興起的非同步式互動機制，其中整套應用程式都被容納在單一頁面內部、而且其使用體驗與案頭應用非常相似。該頁面的載入過程由一系列非同步式調用組成，而且完全由使用者的操作實現觸發。此類解決方案徹底擺脫了根據所需內容向伺服器發送單一調用的傳統機制，從而顯著提高了效能表現並降低網路負載。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服務（例如Google地圖工具）的叫用作業。為了對廣告、地圖、購物車、網路分析、社交媒體模組、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、Firefox以及Chrome瀏覽器都已經提供HTML 5導航定時功能。它能夠將完整的頁面載入時間長度拆分成DNS尋找、重新定向、SSL握手、處理以及緩衝訪問時間長度等具體項目。務必選擇一套具備此類功能的APM解決方案。

650) this.width=650;" title="1.png" style="float:none;" alt="wKioL1QH_rOTFmeqAAF27PgXl6s465.jpg" src="http://s3.51cto.com/wyfs02/M01/48/6D/wKioL1QH_rOTFmeqAAF27PgXl6s465.jpg" />

4.  將問題隔離在特定頁面元素當中
目前瀏覽器所能捕捉的資訊還僅限於完整頁面載入內容，也就是說無法針對個別頁面提供定時資訊，例如載入映像或者圖片、CSS樣式表、指向Web伺服器或者REST API的後端調用所用去的時間。具備網頁分析功能的網路採樣工具則可以為指向單獨頁面對象的HTTP請求與響應計時，從而協助故障排查人員將問題固定在特定頁面元素身上。在選擇網路監控解決方案時，請大家務必確保自己採購的產品具備這項功能。

APM對Web 2.0應用程式實施監控原理

好的APM產品要以客戶為中心、且能夠與APM相協作的解決方案，能夠在資料之外為IT以及業務部門帶來更為確切的答案。除此之外，大家可以選擇將其與資料庫、虛擬化或者網路效能監控機制結合起來，從而進一步發揮APM在整體企業監控戰略當中的全能實力。

650) this.width=650;" title="2.png" style="float:none;" alt="wKiom1QH_q_xYLXRAAKb6T28Zhg236.jpg" src="http://s3.51cto.com/wyfs02/M01/48/6B/wKiom1QH_q_xYLXRAAKb6T28Zhg236.jpg" />

結合傳統與現代解決方案中的諸多優勢要素，APM產品應該具備如下卓越特性：

 能夠捕捉每位使用者的每一次點擊並重現Web使用者的實際活動，從而真正複製使用者使用體驗、從而實現背景資訊取證並完成故障排查。
 利用強大的應用程式運行時架構自動探索機制將我們的應用程式與基礎設施關聯性加以映射。
 確保精確的問題地區識別、詳盡的回應時間分解以及完整的傳輸路徑可視化呈現——從應用程式層到終端使用者，整個流程盡在掌握。
 將所有使用者以及追溯資訊容納在一套以“事務”為核心的通用型架構當中——從而保證資料與工作流程以無縫化方式進行協作，並提供獨一無二的可視化顯示效果。
 彌合虛擬化與共用資源衝突給Web應用程式帶來的影響，保證資料與關係在所有事務維度中的和諧統一——從瀏覽器到資料庫、從代碼層到虛擬機器管理程式。
 利用細緻的根本原因分析機制，在Java與.NET應用程式伺服器內部揪出代碼層瓶頸。
 追蹤每項請求的呼叫堆疊並捕捉相關支援證據，包括記憶體（堆）統計、方法參數以及SQL綁定變數等。
 利用豐富的監控資料與高可擴充性分析機制提供開箱即用的分析與可視化處理方案。

總結

以JavaScript與AJAX為代表的Web 2.0技術體係為Web應用程式帶來了優勢顯著的處理速度提升，同時也讓效能表現與執行效率邁上新的台階。希望APM產品能夠為開發人員給予協助。

本文出自 “聽雲平台” 部落格，請務必保留此出處http://tingyun.blog.51cto.com/9285830/1548706

APM最佳實務：Web 2.0和AJAX四大最佳化戰略