什么是真正的APM（一）

近年來APM行業被越來越多的企業所關注，尤其是在2014年末，NewRelic的成功上市，更加激發了人們對這個行業前景的無限遐想。那么究竟什么是APM？APM的目的是什么？要求我們做什么？有不少企業對APM的理解其實是有偏差的，本文將向您闡述一個真正完整的APM概念。

APM 是Application Performance Managment的縮寫，字面意思很容易理解，“應用性能管理”。它是由Gartner歸納抽象出的一個管理模型。注意，這個管理模型的由來，是經過大量調研與分析后的歸納與抽象，這些切實需求由來已久，IT從業者們對它的理解與實踐也幾乎是從IT誕生至今就已開始，這并不是一次發明。

從上圖中可以清楚看到APM模型中一共分了五個層次，下面就這五個層次逐一說明。

1. End User Experience

What：終端用戶體驗。APM首先關注的是終端用戶對應用性能的真實體驗。

Why：不是監測點的，也不是骨干網核心機房的，而是真實用戶的切實體驗到的性能。可能一個電影播放服務的性能優化做得很棒，但是用戶打開瀏覽器或打開APP，發現點播某個電影時卻慢得離譜，問題會出在哪里呢？用戶不清楚點擊播放按鈕之后，發生的一切事情，用戶只是感知到了慢、不能播放、往復播放等等很多不好的體驗，用戶反饋了問題或投訴了，產品和研發不能準確重現，問題來了。

也許用戶瀏覽器太過陳舊，也許是某個JS腳本的兼容性問題，也許用戶本地網絡丟包嚴重、首字節響應時間很長，也許是服務器集群網絡不穩定、某組機器脫離了均衡池…… 太多也許了。而這些猜測是，最不好把控的，就是用戶客戶端環境，Server端好比自家的菜地，菜好菜賴總是清楚的，可再好的菜賣到飯館，廚子怎么樣菜農怎么知道？

幫助應用管理者準確、詳盡地了解真實的用戶體驗是什么樣子，這是APM首先要解決的問題。

How：對于Web應用來說，在用戶請求到的每一個頁面下面追加一段js腳本，用js收集并發回數據，是最普遍的做法；對于移動App來說，在APP發布前build進SDK，通過系統與語言Hook來收集數據，也是很直截了當的。至于這二者具體的做法，容后文再細聊，此篇不贅。下列簡單截取了幾張圖片，來源透視寶。

What：應用架構映射。

Why: 曾經與多名CTO深入探討過這個問題（其中不乏已經上市的企業）：你們有完整的應用架構圖嗎？得到的回答不少是閃爍其詞的，有的CTO很直接地搖搖頭。更有甚者是這么回答的，公司應用系統年代久遠，就算目前所有的架構師專職繪圖，也很難在短時間內完成全部的應用架構圖。

大多數企業的應用架構，是黑盒或灰盒，這就是現狀。

假如應用架構圖是完整的，那么還有一個需求即：針對于某次故障請求的真實請求鏈路拓撲。是的，負載均衡一共分發了N臺機器作為集群，但承接某次具體請求的是集群中的某些機器，那么，是哪些機器？它們當時的性能是什么樣子？請求順序是怎樣的？

How: 云智慧透視寶實現了應用的完整架構：

與單次請求的應用架構：

可以看到，在上面的示例中，完美了解決了我們在應用架構層面遇到的問題。

具體做法，我們將在后續文章中單獨介紹，其中包含了web容器插件、編程語言Hook插件等技術細節。

 
（未完待續）

關于作者：

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