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

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

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

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

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

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

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

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

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

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

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

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

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

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

端到端应用性能管理

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

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

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

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

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

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

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

Server探针中包含了两部分的功能模块，一部分是数据采集模块，一部分是数据上报模块。采集模块的数据是实时采集的，采集后会由数据上报模块进行本地的汇总统计与合并后再进行上报，因此所消耗的资源和流量都非常小，即使是大规模地部署探针，也不需要非常大的带宽。在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%。

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

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

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

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

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

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

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

这也是我们这几年来一直追求的目标之一，也是我们为什么要做端到端，从主动到被动的全系列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产品，支持更多的云平台服务。在数据分析方面，我们将对采集到的海量数据进行更深的挖掘和分析，为大家提供更多行业性能数据，提供更丰富多彩的应用性能管理报告，作为一种有价值的数据服务提供给用户。