近年来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的架构研发。