雲智慧（北京）科技有限公司高馳濤
近年來APM行業被越來越多的企業所關注，尤其是在2014年末，NewRelic的成功上市，更加激發了人們對這個行業前景的***。那麼究竟什麼是APM？APM的目的是什麼？要求我們做什麼？有不少企業對APM的了解其實是有偏差的，本文将向您闡述一個真正完整的APM概念。
APM 是Application Performance Managment的縮寫，字面意思很容易了解，“應用性能管理”。它是由Gartner歸納抽象出的一個管理模型。注意，這個管理模型的由來，是經過大量調研與分析後的歸納與抽象，這些切實需求由來已久，IT從業者們對它的了解與實踐也幾乎是從IT誕生至今就已開始，這并不是一次發明。
從上圖中可以清楚看到APM模型中一共分了五個層次，下面就這五個層次逐一說明。
1. EndUser Experience
What：終端使用者體驗。APM首先關注的是終端使用者對應用性能的真實體驗。
Why：不是監測點的，也不是骨幹網核心機房的，而是真實使用者的切實體驗到的性能。可能一個電影播放服務的性能優化做得很棒，但是使用者打開浏覽器或打開APP，發現點播某個電影時卻慢得離譜，問題會出在哪裡呢？使用者不清楚點選播放按鈕之後，發生的一切事情，使用者隻是感覺到了慢、不能播放、往複播放等等很多不好的體驗，使用者回報了問題或投訴了，産品和研發不能準确重制，問題來了。
也許使用者浏覽器太過陳舊，也許是某個JS腳本的相容性問題，也許使用者本地網絡丢包嚴重、首位元組響應時間很長，也許是伺服器叢集網絡不穩定、某組機器脫離了均衡池…… 太多也許了。而這些猜測是，最不好把控的，就是使用者用戶端環境，Server端好比自家的菜地，菜好菜賴總是清楚的，可再好的菜賣到飯館，廚子怎麼樣菜農怎麼知道？
幫助應用管理者準确、詳盡地了解真實的使用者體驗是什麼樣子，這是APM首先要解決的問題。
How：對于Web應用來說，在使用者請求到的每一個頁面下面追加一段js腳本，用js收集并發回資料，是最普遍的做法；對于移動App來說，在APP釋出前build進SDK，通過系統與語言Hook來收集資料，也是很直截了當的。至于這二者具體的做法，容後文再細聊，此篇不贅。下列簡單截取了幾張圖檔，來源透視寶。
2. RuntimeApplication Architecture
What：應用架構映射。
Why: 曾經與多名CTO深入探讨過這個問題（其中不乏已經上市的企業）：你們有完整的應用架構圖嗎？得到的回答不少是閃爍其詞的，有的CTO很直接地搖搖頭。更有甚者是這麼回答的，公司應用系統年代久遠，就算目前所有的架構師專職繪圖，也很難在短時間内完成全部的應用架構圖。
大多數企業的應用架構，是黑盒或灰盒，這就是現狀。
假如應用架構圖是完整的，那麼還有一個需求即：針對于某次故障請求的真實請求鍊路拓撲。是的，負載均衡一共分發了N台機器作為叢集，但承接某次具體請求的是叢集中的某些機器，那麼，是哪些機器？它們當時的性能是什麼樣子？請求順序是怎樣的？
How: 雲智慧透視寶實作了應用的完整架構：
與單次請求的應用架構：
可以看到，在上面的示例中，完美了解決了我們在應用架構層面遇到的問題。
具體做法，我們将在後續文章中單獨介紹，其中包含了web容器插件、程式設計語言Hook插件等技術細節。
關于作者：
高馳濤(Neeke)，雲智慧進階架構師，PHP開發組成員，同時也是PECL/SeasLog等多個開源軟體作者與貢獻者。8年研發管理經驗，早期從事大規模企業資訊化研發架構，09年涉足網際網路數字營銷領域并深入研究架構與性能優化。對高并發、高性能、高可用系統設計實作有豐富經驗。崇尚規範、靈活、高效、GettingReal。目前在雲智慧緻力于APM産品的架構與研發。主要負責PHP、Python、Go等語言的底層擴充與SmartAgent的架構研發。