什么是真正的APM（二）

1. Business Transactions

What：應用事務分析

Why：當然這里說的事務不是DB事務。這里指應用與用戶交互的操作事務。舉個例子：用戶登錄網站后，使用搜索功能搜索了耳機，從耳機列表中，選擇了自己喜歡的耳機，打開查看詳情，款式音效價格看來都不錯，放入購物車，然后打開購物車進行購買，完成支付。

整個例子中，我們所說的事務可以抽象為：

登錄 -> 搜索 -> 挑選 -> 購買 -> 支付

所以，單純的記錄登錄成功率、購買成功率的意義不會至于大到分析整個應用的健壯穩定程度，準確地分析出整體事務的相互影響象限，才會。

How：熟悉GA的朋友都知道，GA花費了大量的力量以實現上述我們所描述的應用事務。但令開發者痛苦的是，必須要在代碼中“埋點”，即在代碼中的關鍵位置寫入一行代碼，以實現在關鍵位置的追蹤，而業務總不是一成不變的，于是隨著業務發展，“埋點”這個事情使得應用總在不停地修改、發布、修改、發布。

其實，用戶在客戶端（瀏覽器、APP）所進行的所有操作，很明顯，是有序的。要完成應用事務的記錄，要完成的需求其實只是兩個惟一性：

1、確定上下文的事務操作，是同一個用戶；

2、確定所有事務操作的每一個步驟，是惟一一個動作。

于是我們便可對某一個應用取得的數據分析出以下應用事務，而整個過程中，用戶不需要修改任何一行代碼（無須埋點）。 具體的實現細節，后續會專門出文介紹。

2. Deep Dive Component Monitoring

What：深度應用診斷

Why：關鍵詞是“深度”。比如某在線商城，接到了上海用戶的反饋，登錄慢，不響應。這其中可能出現問題的環節太多了：CDN可能有問題、Web Server或DB Server負載可能過高、業務代碼中可能有bug、中間件可能不響應、甚至任何一個環節的物理磁盤或物理網卡可能出現了故障，等等。想要準確地找到問題所在，即使不經一番寒徹骨，八成也要先打個冷戰。

How：這里有幾個難點是：

1、在不修改用戶代碼的前提下，取得代碼運行時性能數據；

2、終端用戶數據、運行時性能數據、物理指標數據、服務運行指標數據，有效關聯；

3、有太多需關注的點，怎樣方便快捷地部署采集端；

4、不影響或很少影響原應用性能。

以上也正是APM提出的需求。

一鍵式的、無干預的安裝部署與更新升級，以替代繁瑣的部署與升級；采用各個語言的底層Hook來針對性地編寫語言Agent插件，以此實現不修改用戶代碼而取得運行時性能數據；通過主機、應用、服務、請求的惟一標識，來進行有效的數據關聯；通過特有的數據采樣算法來達到2%以下的性能影響；一體化的數據模型，以替代密集的數據孤島。這段特征，描述的是云智慧透視寶的Smart Agent。（同樣，實現細節請待后文。）

3. Analytics / Reporting

What：分析與報告

Why：簡單地講，APM對數據有兩點要求：

1、數據處理要及時，必要時候要做到實時的處理，問題可能隨時都會發生；

2、數據的分析報告要精確，大量的數據本身是無價值的，按照業務模型進行精確分析、預測才有其價值體現。

How：APM數據是天然的大數據，符合4V特征。因此難點幾乎與大數據處理的難點相重合：

1、數據模型語言要統一

2、數據存儲與查詢

3、大量復雜數據的關系建模

 

下圖是對比了國內外APM行業的各廠商對以上APM模型中五個層次的認識與支持程度：

-------

End

關于作者：

高馳濤(Neeke)，云智慧高級架構師，PHP開發組成員，同時也是PECL/SeasLog等多個開源軟件作者與貢獻者。8年研發管理經驗，早期從事大規模企業信息化研發架構，09年涉足互聯網數字營銷領域并深入研究架構與性能優化。對高并發、高性能、高可用系統設計實現有豐富經驗。崇尚規范、敏捷、高效、GettingReal。目前在云智慧致力于APM產品的架構與研發。主要負責PHP、Python、Go等語言的底層擴展與SmartAgent的架構研發。