2016年11月24日-25日，以“技术源动力”为主题的GITC2016在北京国家会议中心盛大召开，听云资深测试专家任燕萍围绕着性能、业务运维等当下技术热点在大会现场进行了《全栈溯源-追溯性能问题根源》主题分享。现场解读了在复杂应用环境下，精确定位并判断网络、移动端、浏览器端、服务端性能问题根源，高效地解决问题的经验。
以下为演讲实录：
任燕萍：大家下午好，非常高兴也非常荣幸成为今天上台的唯一一个女嘉宾，其实内心也非常紧张。之前有很多大拿也已经分享了很多关于运维的一些指标和监控的一些方案，今天分享的全栈溯源是和运维分享的技术点是息息相关的，希望能和在座的各位大拿产生共鸣。
全栈溯源是APM领域比较有价值也比较有技术含量的解决方案之一，意思是在复杂应用环境下使用APM来追溯服务器端，网络端，浏览器端、移动端性能问题的根源。今天是讲利用全栈溯源来解决一些实际复杂应用环境下出现的问题。
一、为什么用户离我远去……
这是一个传统的应用服务器的架构图，在传统应用部署模式下会存在很多盲点或者说叫坑。从右往左看，用户用不同的移动设备或浏览器来访问一个网站或提出一个请求，会经过运营商、互联网、CDN，最后到达后端的应用服务器。在这整个过程之中，比如说浏览器的渲染性能不是特别好，手机的某一个线程设计的不是特别合理的话，也会影响到系统的活跃性，再比如说请求访问网络端， DNS解析失败，或者说CDN策略设计不是特别合理的话，也会影响到系统的活跃性。那么即使浏览器的渲染能力特别的好，网络特别稳定、CDN策略也设计的特别合理，最后请求到达应用服务器端，比如说有做负载均衡， web应用服务器收到请求以后是如何将请求下发到后端的服务节点，那么各个节点在受到请求之后，又是如何来处理请求，在这整个过程当中，每一个服务节点出现问题，都可能导致应用性能的下降，因此在这种复杂应用的环境下，就需要使用一些先进的技术来保证系统的稳定。
最近流行的一个话题叫做微服务，所有的企业都在做一些服务的拆分，在做一些RPC分布部署，为什么用户还会渐渐的离我们远去呢?
在对市场做了一个调查后发现，用户会产生市场流失，比如说国家政策导致的流失。还有一些是受挫流失，比如说新用户上手难度大，产品的功能不符合用户的需求。当然还有自然的流失，比如说迭代缓慢导致。但是这其中最重要的还是用户体验。大家都在谈用户体验，那么什么是好的用户体验?一个好的用户体验不单是用户在使用服务的时候他的功能能够得到很好的满足，在性能方面，系统的稳定性也会是一个衡量用户体验好坏的非常重要的指标。
那么APM在解决这种用户体验的问题上，把端到端做了一个切片化的处理，比如说在网络端，能够拿到首包时间、DNS解析时间等，那么在APP上呢，可以拿到页面的处理时间、图像的处理时间。在浏览器端，可以拿到页面的渲染时间，dom解析时间等。最后在服务器端，可以拿到NoSQL的协议时间，数据库的处理时间,最后将这些切片的时间串起来，就会形成一个追踪流。
二、全栈溯源的基本概念
全栈溯源是为了提高用户体验来进行一个阐述，主要是包括全栈溯源的定义、价值、案例以及实现原理。
首先来看全栈溯源的定义。
所谓全栈，是指网络端、移动端、浏览器端以及服务器端。溯是指追溯，源是指根源。那么所谓全栈溯源是指在复杂的应用环境下，精确定位并判断网络、移动端、浏览器端、服务端性能问题根源的技术手段。
在随着架构演进，现在很多企业都在做一些微服务的拆分。那么这就存在一定的问题，就是逻辑拓扑会演变的非常复杂，应用的调用关系会变成一个碗状的结构，甚至组件之间会采用不同的语言来实现，比如前端会使用PHP或Ruby，后端会使用.Net或Java，在这种复杂的应用环境下，要保证系统性能的稳定是一个非常大的挑战。比如说通过APP来发送一个请求很慢，最终的定位是由于服务器端的一个SQL语句写的有问题导致的。比如说用浏览器发送一个请求，发现首包时间慢，最后发现是因为后端服务器调用了一个Web接口导致的，等等。
因此全栈溯源提供了以下四个解决方案，来定位以上的这些问题。
从移动端到服务端的性能溯源
从网络到服务端的性能溯源
从浏览器端到服务端的性能溯源
服务端跨语言跨应用的性能溯源
谈了这么多，那么全栈溯源能带来什么价值呢?大概是以下几点：
降低跨部门排障沟通成本
从3天到5分钟快速追溯性能问题根源
性能问题界定，协助运维明确责任，协助研发修改问题
完整业务调用链跟踪(业务、运维、研发)
在过去的时候呢，客服人员或者技术人员会收到一些投诉网站访问的很慢， 运维的人去查是不是网络出现了问题，DBA回去查是不是数据库除了什么问题，研发人员会去查log来分析是不是代码写的有问题，这样就会导致跨部门之间的沟通障碍非常的大，甚至解决一个问题要五天甚至更长的时间。那么有了全栈溯源就可以设置一些警报，在用户投诉之前就可以通过邮件、短信甚至微信的方式来指出具体是哪块出了问题，这样使得解决问题的过程大大缩短。
过去运维人员会背过很多的黑锅，那么全栈溯源便被称为一个甩锅神器，就是因为可以第一时间通过报表知道到底是谁的问题。以前研发定位问题会通过大量的日志去分析，去看异常出现在哪个应用里，那么有了全栈溯源的话，就可以在几分钟之内定位并解决问题。
三、全站溯源的案例
模拟了一套电商的系统，模拟用户登录、选商品，加购物车，下订单去支付等等，这样一整套流程里面去模拟这样一些问题的点，它包括以下一些场景：
场景一、登录缓慢 (APP~Server) [HTTP]
场景二、商品选择操作缓慢 (Browser~Server) [HTTP]
场景三、订单提交失败 (Network~Server) [HTTP]
场景四、用户信用检查故障 (Server~Server) [JMS]
场景一、登录缓慢 (APP~Server) [HTTP]
在APP端发现登录端非常缓慢，怎么样定位这个问题呢?还有通过http的协议，有一个商品选择操作缓慢等，最终最严重的问题是订单提交失败，订单提交失败就意味着没产生资金交易。除了这些信息以外还有现在大家都在讲征信的系统，其实电商也会有这样一套系统，你每一次去买一个东西的时候，他会去查你整个用户信用情况是什么样的，如果在查询用户信用的时候出现了故障也会导致整个支付的中断，在这几种场景下我们来看到底是什么原因导致了整个用户体验的缓慢。
上图是一套期望的逻辑拓扑，通过手机APP，通过页面访问不同的Portal，比如部署在Azure上的Azure Web Role会接受APP的请求，然后将不同的请求分发到对应的Service，以及最终订单的信息，这是我们最初的一个希望的逻辑拓扑。但是这些系统在匆忙上线之后出现了一个问题，我们有一天收到一个警报，说其中大量用户出现了登录拥塞，通过一些信息去看因为其中一个登录的接口平均消耗了9秒的时间，这是不可以接受的。我们看到这次登录的接口它的TCP时间、SSL时间、网络传输时间都非常快，只有一个首包时间比较慢。通过这样一次钻取想去看到底这次登录接口是哪一个服务为登录提供服务。
下图会看到一个ASP应用过程为登录提供服务，在这个登录的过程中看到其中有很大的一个延迟区块是因为它访问了另外一个服务，通过这样一层信息的获取我们就知道登录时间问题根源不是在APP端，而是因为服务器端部署在上面的应用出现了问题，这个应用因为访问了其它的应用，导致这个应用为APP提供服务的时候出现了问题。但是这样还不足以说明我们到底哪些用户受到影响，当单一用户受到影响的时候它都已经走过了哪些轨迹。
所以需要看单一场景下的一个用户，下图是在手机上抓取到的，在这个里面可以看到CPU没有问题，内存消耗也非常正常，而是在网络请求的请求消耗了绝大多数时间，他调用了其中的一个login.aspx这个服务，这个服务占了20多秒，这20多秒究竟花在什么地方，到底如何切片，去追踪看这个服务到底它有哪些切片。
上图是这个服务跟刚才的片子对应，再看下DB操作，是因为哪一行代码调用了DB操作。可以看到有一个service，这样的service到底执行了什么样的操作，它大概执行了这么几个操作，其中一个语句消耗了18秒的时间，有了这个信息就可以根据这个信息就找到了问题的元凶。
场景二、商品选择操作缓慢 (Browser~Server) [HTTP]
再来看场景二，商品选择非常缓慢。这个时候通过浏览器将这条商品加在购物车里面的时候，不知道它到底经过了哪些后续的操作，但是可以感受到的是它非常慢，在这样的一个应用过程叫选择，下图可以看到在整个24秒时间里面，其中在服务器响应时间里可以占到90%，这个时候到底这90%的时间是哪个服务提供了服务。
从商品选择的服务去看它的一些业务操作，除了本身一些业务代码操作还去访问了一个商品列表的操作，这个列表是一个.NET的应用，从这可以看到整个商品选择缓慢可能不是我的页面处理问题，也不是因为提供商品节选的问题，而是说我调用了.NET的服务出现了问题。同样的原理还是没办法知道用户在这个情况下的具体问题。
一个用户在访问这个页面的时候，可以看到他客户端的IP在整个情况下因为对URL的调用产生了30秒的时间，这30秒的时间大概花在哪里?
可以看到在这个服务里面在这行代码因为.NET对本地服务操作消耗了很长时间，这样就可以知道这次用户选择商品慢是因为.NET的操作慢。
场景三、订单提交失败 (Network~Server) [HTTP]
再去看另外一个场景，订单提交失败，这是一个很严重的问题，关系到钱的问题，我们通过这样一个全景图去看到在全国范围内的情况，颜色越重就说明时间消耗越长，用户体验越差。老板看到这个图会非常不高兴，为什么在这么多地区都出现了这样的问题。
那么问题来了，在所有的请求里面大致的分布是什么样的?所有的请求里面有绝大多数是处于60秒以下的，但一些极端的情况下超过了120秒，120秒是不可以忍受的，所以能不能知道这120秒到底消耗在哪?
在这样的一个事物流程里面包括登录、商品选择、订单提交，我们会发现在订单提交最后一步出现了问题，而导致整个订单失败。在订单提交里面其实是调用了一个URL，响应时间大概是27秒，这27秒我们怎么样去做分解?
将这27秒做分解以后发现，又是数据库的问题，还是想知道这个数据库到底执行了什么样的语句，这里面就可以知道数据库是因为查询了一个表的操作导致的。
这个时候有了这个表可以看到执行计划是什么，这个表是不是因为单表的数据量过大，而导致了整个请求的拥塞，这就是在订单处理的时候出现问题如何查找这个问题原因的过程。
场景四、用户信用检查故障 (Server~Server) [JMS]
现在都在提数据流，在处理数据流的时候会使用MQ做这种消息处理负载，在处理消息字节上的等待时间出现问题也会对用户体验造成影响。因为消息没有处理完，所以信用检查也没有处理完，导致整个消息没有回传过来，所以用户的信用检查就卡在这儿。我们来看这个消息检查他做了什么样的操作导致延时会这么长?比如说他是因为调用了另外的一个支付网关的服务，而这个支付网关给他的响应很慢，当然这里面是我们模拟的一些数据。
支付网关接入如果是支付宝、微信导致了在整个订单的过渡中出现了问题，就可以跟支付宝，微信的团队去沟通，为什么这个接口这么慢，在这里会看到因为在这个消息解析的时候，他访问了一个支付网关出现了问题，而导致了整个的清理检查的失败。这就是整个场景里面对于我们刚才这个问题的一个解答。
下图是我们实际能够抓出来的一些逻辑拓扑。
除了这些大面积的拓扑，它的单一拓扑也在一定程度上会帮助我们快速的定位这个问题，比如刚才说login.NET这样的接口，它调用了JDBC的拓扑，这是单一用户请求下的一个拓扑，这样也能快速的解释是不是因为DB出现了问题而导致了整个服务出现了问题。
四、全栈溯源的实现原理
这是听云的一个全景图，端到端分为客户端到服务器端，听雨Server、听云Browser、听云App、听云Network。听云Network是一种主动式的监控，听云Browser是使用JS嵌入的方式来监控，听云App是使用SDK嵌入的方式来监控，听云Server是通过植入探针的方式来监控。
下图是听云全栈溯源的概览图，这个图里能看出听云产品中一些更详细的功能。
那么实现这些功能，做到的第一步就是数据采集。这个时候就会有很多的用户很关心，听云采集了这么多数据，而且还采用了非常多的技术手段，比如说嵌入SDK，植入一些探针。那么在采集数据的同时会不会改变到原有的业务或者性能。接下来我对我们所用到的技术来做一个介绍，这样会消除你们的一些顾虑。
浏览器端我们是用的是JS注入的方式，移动端安卓是使用字节码的方式，iOS端是使用Hook的方式。网络断也是Hook方式，服务器端-JAVA使用的也是字节码的方式，PHP使用的扩展的机制，.NET是使用ILRewrite的机制。
下面我来一一介绍一下。在浏览器端我们是用的是JS注入的方式，我们是调用了浏览器提供的一个**的接口来获取页面性能的数据。对于错误的数据是监控了Windows提供的一个IO事件来捕捉JS的异常信息。对于Ajax我们采用的也是HOOK的机制。
下图是听云字节码实现的方式，比如说xxoo这个方法，我们想要获得它的性能数据,在前和后加入一个时间戳，相互一剪得到这个方法的响应时间。包括一些异常的数据，我们可以加入一个try-catch来捕获他的异常，最终来上传到听云平台。
下图是我们网络端获取数据的原理，我们是通过调入浏览器的内核来获取整个网络端的数据。
服务端数据采集原理我来介绍下Java吧，Java探针的采集原理是在JVM加载Class文件之前，通过ClassLoader先加载这些字节码，通过字节码技术来进行一个埋点，最终来上报一些我们想要的数据，比如NoSQL的数据，方法的执行时间等等，最后做一个统计上传到我们的数据统计服务器。
接下来来回顾下今天分享的产品，主要是我们听云的四条产品线，听云App、听云Network、听云Server和听云Browser。因为今天分享的主题是全栈溯源，因此我分享的四个案例最终问题的根源都是在服务器端。但是在我们工作的过程中遇到的问题不单是在服务器端，有可能是任何一端。
