五、仪表板与使用情况

　　要让大家更好地感受两款工具的实际用户体验以及解决问题的方式，我认为最理想的办法就是通过视频演示来说明。不过在此之前，需要强调的是AppDynamics使用的仪表板以Flash为基础……没错，就是Flash，看来这套搞得天怒人怨的方案还没彻底消失。虽然采用Flash看起来是种倒退，但AppDynamics本身可能算得上是我所见过的最出色的Flash应用程序(需翻墙)：

　　http://www.youtube.com/embed/doSM9lSD2so?rel=0

　　NewRelic方面在TypeSafe上发布了一段网络讲座视频，其中对New Relic方案的方方面面进行了说明(视频内容确实有点长，但如果大家确实打算部署自己的APM方案，那么其讲解效果还是非常出色的，需翻墙)：

　　http://www.youtube.com/embed/LJL7EAavb1Q?rel=0

　　听云的仪表盘：基于HTML 5的自定义仪表盘，用户可向仪表盘中添加任意一个在听云平台上看到的图表，并可自由拖拽图表的排列，非常适合运维NOC在大屏幕上展示重点关注的性能指标项。由于采用HTML 5的仪表盘，除了支持传统PC平台的访问，更可方便地在各移动平台设备上提供一致的访问体验。

　　总结: 三款工具都提供良好的使用体验，但在布局方面全世界的APM解决方案都显得有些杂乱。

　　六、 安装

　　1、SaaS/内部环境: AppDynamics和听云提供多种操作模式——包括SaaS、内部以及混合型机制，每一种都提供各自的安装指导说明。其中听云Network无需用户对生产环境做任何改动即可立即使用，只需要在听云Network平台上配置需要监测的应用的URL，几分钟后即可看到实时的性能数据。而New Relic则只支持SaaS这一种模式。

　　2、代理: 要对自己的应用程序进行监控，我们需要借助指向服务器的附加语言指定代理。举例来说，在Java方面我们有两种可能性选择利用代理将代码引入设备，即利用Java代理或者利用本地代理。New Relic与AppDynamics在收集报告所需的性能数据时，使用的都是Java代理。而为了获取低层级数据来指明错误位置并帮助解决问题，Takipi则会使用本地代理。

　　3、代码与配置变更: 在真实用户监控方案当中，如果大家需要向自己的Web或者移动应用程序中添加监控功能，那么项目与配置变更所包含的必要关联性就变得必不可少。其中包括向我们的网站添加JS代理或者向移动应用程序中添加本地移动代理等。

　　4、警报: AppDynamics自身会计算我们的响应时间阈值，而且可能需要花费一段时间来检查并识别当前系统。听云和New Relic则要求大家为其Apdex指数以自定义方式设置阈值。

　　总结：如果大家需要一套内部运行版本，那么最理想的方案明显应该是听云。如果没有此类要求，那么三者在安装流程方面都很简单——只是New Relic在警报设置层面要更复杂一些。

　　结论

　　AppDynamics、New Relic与听云可以说是目前市面上的应用最为广泛的APM工具，而且从传统角度上面向不同类型的开发人员——从全球到中国、从大型企业到初创公司。不过从三家方案中选择其一已经成为没有确切答案的问题，大家只需要明确一点——内部环境运行时不能选择New Relic，只能选择AppDynamics和听云!

　　本文中Appdynamics、New Relic、听云从受支持环境、具体功能、解决错误仪表板及使用、安装、价格这几项对比分析是否让你已经很清晰地了解到了如何选择适合你的应用性能解决方案了呢?笔者认为，不论使用哪款产品，作为开发者的你都是希望自己的产品能超越其他，在这竞争激烈的移动互联网时代脱引而出，不是吗?