基于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