听云 CTO 访谈：解读现代应用性能管理 (APM) 技术

随着互联网的发展，越来越多的 IT 企业和部门开始越来越重视应用性能管理。听云在该领域耕耘多年，并于前段时间发布了《2014 中国移动应用性能管理白皮书》，对国内移动应用的性能问题进行了总结。InfoQ 记者对其 CTO Wood 进行了采访，谈到了真实用户体验监测、Synthetic 监测、端到端应用性能管理、SaaS 与隐私、大规模分布式系统应用性能管理等问题。

InfoQ：你们最近发布了《2014 中国移动应用性能管理白皮书》，里面提到移动应用性能的五个度量维度：崩溃、错误、网络请求响应时间、交互性能、运营商网络响应时间。能否分别说说为何是这五个维度？

Wood：我们在 2013 年发布了移动 App 性能管理产品，用来为 App 开发者和服务商提供 Native App 性能和用户体验监测服务。这一年半以来，我们采集了大量的 App 和设备的性能数据，并且在服务这些客户的过程中，总结了一些我们的用户最关心的问题来作为此次白皮书的关注重点，这 5 个维度基本上都是我们的用户，特别是 DevOps 团队最关心的问题。

崩溃：App 的崩溃属于性能监测中的应用可用性范畴，也是最影响用户体验的问题，因此我们将崩溃的分析放到了第一位。

错误：App 内发生的错误同样是影响应用可用性和用户体验的严重问题。目前我们的错误分析包括网络错误和服务端的 HTTP 错误两大类，当一些关键的业务接口出现错误时，将会导致用户的大量流失。从长期监测数据来看，App 的错误率和用户流失率呈现一定程度的正相关关系，我们还发现有些 App 开发者不合理的错误异常处理会导致 App 耗电量的大量上升，造成用户体验下降。

网络请求响应时间：请求响应时间指的是 App 发起的网络请求从请求开始到完整收到响应内容结束的时间。请求响应时间会受诸多因素的影响，特别是网络延时、数据量和服务器端的应用的响应性能。这个指标是评估最终 App 性能的关键业务指标，App 用户的耐心是有限度的，当网络请求响应慢的时候，用户无法在预期的时间内得到想要的信息时，很容易放弃对 App 的使用，造成用户流失。

交互性能：交互性能指的是用户在使用 App 的过程中 App 对用户交互行为的响应性能。对最终用户来说，对用户体验最直接的主观感受就是交互的性能。这部分的性能会受前面提到的网络请求响应时间影响之外，更多会受 App 本地代码的执行效率的影响。

运营商响应时间：这个其实是后加进来的，原因是基本上所有用户在使用我们的产品之前都不了解各地各运营商的访问性能差异，希望对此能有一个大概的了解。而运营商之间的互联互通问题也算是中国的特色，在我们几年监测数据和服务的过程中也发现很多的性能问题确实都是受运营商之间的链路问题导致的。

这次的白皮书是我们第一次面向市场对几年来积累的经验和数据的总结，也是一个全新的尝试。这 5 个维度的数据可以让大家对国内的移动应用的性能有一个大概的了解，但是并不能代表全部的问题。我们还在持续进行改进，采集更多维度、更加完整的性能数据，希望在将来的报告中为大家带来更多有价值的数据分享，也欢迎大家来下载我们的数据报告。我们还推出新的报告《中国网络性能报告》，欢迎大家关注。

InfoQ：在你们的产品描述里提到真实用户体验监测，什么是真实用户体验监测？

Wood：真实用户体验监测是 APM 应用性能管理中的一种数据采集方式。相对于主动式的模拟用户方式的数据采集形式，真实用户体验监测采用的是被动的数据采集形式，它是通过在真实用户对应用进行访问的过程来采集性能和用户体验数据的。相比主动式的模拟监测，真实用户体验监测的优点在于全样本的监测数据，可以做到没有样本偏差，也就是你看到的数据就是你真正用户正在遭受的性能问题。

InfoQ：还有什么是 Synthetic 监测，能否从技术维度深度解析端到端的应用性能管理这个词？

Wood：Synthetic 从字面的含义是“人工的、合成的”，在 APM 领域内，Synthetic 监测特指的是主动式的模拟用户监测。听云 Network 就是一款 Synthetic 监测产品。

Synthetic 监测非常适合来网络层面的性能监测，因为是主动式的探测，可以做的探测比较多，也能采集到非常详细的网络等性能数据。另外，我们的第三方性能评估的身份也正是 Synthetic 监测方式所带来的。由于使用的是主动式的模拟探针，用户既可以监测自己服务的应用和网络性能，也可以监测竞品和服务提供商提供的服务的性能，可以提供竞品对标、IDC/CDN/ 云服务商等服务选型和服务质量监测等一系列特定的性能监测服务，这也是其他的监测方式所无法提供的。

此外，采用 Synthetic 监测方式的听云 Network 还可以提供互联网环境下的压力测试，并且可以结合 Server 性能管理的应用追踪和剖析功能，在一些性能敏感型的大并发访问量的应用（例如电商的秒杀和各种日期的促销活动）正式上线前就可以提前知道应用的性能瓶颈，并在正式发布前进行相关的优化。

Synthetic 监测相比真实用户体验监测存在最大的不足是样本偏差。因为执行 Synthetic 监测的监测点与真实访问应用的最终用户所处的网络、设备和软件环境可能存在的差异，当监测样本点较少时，可能会导致在测试的结果上出现比较大的样本偏差。当然样本偏差是可以通过合理选择样本的分布、增加样本的数量、以及使用合理的统计算法来在一定范围内降低和消除的。而在进行竞品对比测试时，是不受样本偏差的影响的。

端到端的应用性能管理从技术层面上来解释，指的是从应用的用户端到服务端都同时进行应用性能的监控和管理。由于导致应用出现性能问题的原因是多种多样的，广泛地分布在从用户端到应用服务端的各个访问路径和层面上，例如：App 内部代码的执行效率问题、接入设备的运营商和网络问题、第三方服务商提供的服务问题这些都只有在用户端进行数据采集才能发现。而服务端的应用代码问题、后端的数据库等各类服务响应性能问题，是站在用户端无法发现的，只有从服务端进行数据采集才能获取这些数据。因此，在进行应用性能监测和管理的时候，只有同时从两端来采集数据进行汇总分析才能全面地了解应用的性能数据，并且在出现性能瓶颈的时候快速准确地定位问题点。

端到端应用性能管理

InfoQ：App 性能监控和 App 测试平台 / 工具有哪些区别？

Wood：App 性能监控和 App 测试平台 / 工具的最主要区别在于它们适用于 App 应用生命周期中的不同阶段和不同的运行环境。

在一个典型的 App 应用生命周期中，一般会经历需求 -> 设计 -> 开发 -> 测试 -> 发布运营 -> 反馈再回到需求整理的过程。在这个过程中，App 测试平台和工具适用的是发布前的开发和测试阶段，是在测试环境下使用的工具，提供包括应用性能、软硬件适配和兼容性、业务代码正确性的诸多层面的测试功能，保证的是 App 在发布前的质量，虽然也可以提供应用的性能测试，但这些测试数据都是在实验室测试环境下得到的。

我们的 App 性能监控针对的是 App 发布之后在运营阶段的发布后性能质量管理，是在生产环境下使用的服务。即使发布的 App 经过了严格的测试，在发布到生产环境下以后，由于运行应用的设备、网络、第三方服务、自身服务等诸多环境的复杂性和不可预知性，很可能会导致很多不可预见的性能问题和故障，因此针对生产环境下提供实时的 App 性能监控对一个 App 的持续稳定运营是必不可少的。

InfoQ：你们的 App 监测引擎使用了哪些技术？

Wood：我们的监测引擎使用的技术比较多，其中最主要的技术是自动代码注入技术。

通过该技术，我们的 SDK 可以自动地在 App 编译时或者运行时对用户的 App 代码实现监控代码的注入。通过自动代码的注入方式，我们极大地减少了用户的开发人员使用 SDK 的工作量，开发人员总共只需要阅读一页的说明文档，增加两行代码即可完成 SDK 的集成，而不需要在 App 中到处添加代码，最大限度地降低了 SDK 的使用门槛，让 App 开发者可以把精力集中在自己的业务代码开发上。

在该自动代码注入技术中，我们还加入了动态的数据采集技术，通过该技术，我们最大限度地减少了注入到用户代码中的监测代码的代码量和运行时间，同时又可以动态地根据需要调整采集的数据详细程度和数据量。通过动态数据采集技术，我们既可以在基本不影响应用性能的情况下实时采集性能数据，又可以在应用出现性能问题的时候采集更详尽的性能数据来帮助用户定位问题。

InfoQ：你们的 Server 性能管理如何支持大规模分布式应用的性能监控？

Wood：可通过在大规模分布式应用的各应用实例上全样本或者采样部署 Server 探针的方式来支持大规模分布式应用的性能监控。

Server 探针中包含了两部分的功能模块，一部分是数据采集模块，一部分是数据上报模块。采集模块的数据是实时采集的，采集后会由数据上报模块进行本地的汇总统计与合并后再进行上报，因此所消耗的资源和流量都非常小，即使是大规模地部署探针，也不需要非常大的带宽。在 Server 的报表控制台上，对大规模分布式应用，用户也可以选择从整个应用维度、主机维度和实例维度来分别进行数据的查询和分析。

InfoQ：你们的 Server 性能监控的粒度如何，对性能的影响如何？

Wood：粒度最细可以达到 1 分钟，从探针采集到的性能数据就是以 1 分钟的频率上报到数据中心进行汇总统计的。在 Server 的控制台上，根据选择的图表时间窗口的不同，报表的数据展现粒度可以从 1 分钟到 3 天自动调整。

我们的 Server 探针作为一款侵入式的性能采集器，肯定是会对应用的性能产生影

响的，我们目前版本的探针对应用性能的影响的平均值是 3%，也就是如果您的应用在不安装探针的情况下的平均响应时间是 100ms 的话，安装完 Server 探针后的平均响应时间大概会变成 103ms，基本上对应用性能的影响是可以忽略的。这已经可以比肩甚至超越 New Relic 等在内的全球顶级 APM 服务提供商的性能消耗。

如何尽量减少对应用性能的影响是我们 Server 性能管理开发中最大的挑战，如前面所提到的，Server 探针分为两大部分的功能模块：数据采集模块和数据上报模块。数据采集模块的代码是通过自动代码注入引擎注入到用户的应用的代码中的，会与用户的应用代码一起运行，这部分的代码是会影响用户的应用性能的。而数据上报模块负责汇总和上报数据，是作为独立的进程（例如 PHP 探针）或独立线程（例如 Java 探针）来运行的，这部分代码是不会影响用户应用的性能的。

我们通过尽量降低数据采集模块的代码的复杂程度来降低这部分代码对用户应用的影响。实际上这部分代码真的是非常简单，最主要的代码就是记录时间戳，也就是在进入和退出需要被监控的代码块或方法的时候记录时间戳。所以说这部分代码对用户的应用带来的性能影响的程度与这些计时代码被调用的次数和执行时间密切相关，当一个用户应用的性能恶化是由于代码的调用复杂程度增加或应用本身的负载升高导致的时候，Server 探针所带来的平均性能影响数值是保持 3% 的线性增长的。例如应用的响应性能因为代码调用的频度增加或服务器性能下降从原来的 100ms 变成 200ms 时，Server 探针带来的附加响应时间会从原来的 3ms 变成 6ms。但是当应用的性能恶化是由于应用所调用的其他后端服务（例如 SQL 数据库查询）性能恶化所导致的时候，Server 探针所带来的附加响应时间就不会线性增加了。例如在上面的例子里，当应用的性能下降是由于后端数据库服务器的查询变慢从 100ms 变成 200ms 时，Server 探针所带来的附加响应时间会保持 3ms 不变，从而性能影响百分比会小于 3%。

InfoQ：你们的 Server 性能管理对 NoSQL 的支持如何？

Wood：现在越来越多新型的互联网应用除了适用传统的关系型数据库之外，还会根据业务的需要选用一些 NoSQL 服务来提高应用的性能，提升用户体验。但是当这些服务使用不当时，依然会出现性能问题。

因此我们也将这部分服务纳入的应用性能监控范围内。目前我们支持比较常见的 Memcached, Redis 和 MongoDB 三种 NoSQL 服务，后续还会支持更多类型的后端服务，这也是国内唯一完整支持 NoSQL 性能监控的 APM 解决方案。

InfoQ：对于 SaaS 模式的 APM，你们如何保证客户的数据安全和隐私？

Wood：首先，我们从法律上进行数据安全和隐私的保护。在我们的服务合同中会向客户承诺，除非得到用户的允许，所有用户帐号下的数据都不允许透露给任何第三方的个人和组织机构。

其次，我们运行用户对采集的数据进行保护和混淆。例如我们为 App 开发者提供 API 接口，对想隐藏真实日活 / 月活用户数的 App 进行不透明的采样。在 Server 性能管理上，探针可以对采集到的服务器端的 SQL 语句，用户提交的表单参数进行数据混淆，这种混淆是无法还原的，保证了一些敏感的用户数据（例如：用户名，密码等）不会被采集和提交。我们的探针还有一个安全审计模式，当运行在该模式下的时候，所有探针采集和提交的数据都会被记录到本地的安全审计日志中，用户的安全审计人员可以对采集的数据进行安全审计，来决定是否有不能对外提交的数据，然后通过设置混淆的方式将这些数据过滤或者混淆掉。

第三，我们使用加密的传输协议来保证采集的数据在互联网上传输的安全，使用强证书的校验来防止中间人攻击，防止数据在传输的过程中被截取和窃听。

最后，在 Saas 平台上，我们与云服务提供商以及安全厂商一起合作，在网站平台安全上，在数据加密和存储上做了很多的工作，来保证用户数据的安全。

InfoQ：从你们在客户的接触中，了解到的客户对 APM 最需求的点是什么？

Wood：从我们这 8 年多服务客户的过程中，我们发现客户对 APM 服务最根本的需求就是在最需要的时候快速准确地定位性能瓶颈和故障。这一点在很多客户那边，特别是电商客户，都有非常强烈的需求。因为电商的促销和秒杀等活动都是对服务的性能要求非常高的，能否在性能下降和故障发生的时候快速准确地定位故障点并迅速解决，是保证活动成功和销售额达成的重要保障。

这也是我们这几年来一直追求的目标之一，也是我们为什么要做端到端，从主动到被动的全系列 APM 产品的原因。

InfoQ：请问你们的 APM 研发经历了哪些阶段？未来有什么计划？

Wood：我们这 8 年的 APM 探索经历了从客户端到服务端，从外部到内部，从 PC 到移动，从主动到被动的过程。

我们前几年主要的产品是基于 PC 浏览器的主动式拨测的 APM 产品：听云 Network。该产品主要解决了用户在 Web App 用户体验优化、IDC/CDN/ 云服务选型、网络优化、竞品性能对比等方面的需求。

我们大概在 2009 年就开始了移动互联网 APM 技术的探索，先后推出了模拟移动监测、真机移动监测和听云 App 产品，一系列的移动监测产品主要解决的是用户在移动网络特别是各运营商弱网环境下、不同终端设备和系统下的性能问题。

从客户端的 APM 产品上，我们更多看到的网络和终端层面的性能问题，而当性能问题出现在防火墙之后的时候就束手无策了，因此我们在 2013 年开始服务端的 APM 产品的研发，最终在 2014 年发布了听云 Server，针对的是应用的服务端在代码、数据库、NoSQL 等其他后端服务的性能监控和问题定位。

未来几年，我们将继续专注在 APM 技术的研发上，主要的方向还是移动、云和大数据，在移动方面会支持更多类型的移动设备和平台，支持 H5 和混合型的 App。在云上我们会与各家云服务商密切合作，为云用户提供简单易用的云端 APM 产品，支持更多的云平台服务。在数据分析方面，我们将对采集到的海量数据进行更深的挖掘和分析，为大家提供更多行业性能数据，提供更丰富多彩的应用性能管理报告，作为一种有价值的数据服务提供给用户。

感谢崔康对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群）。