我们现在面临一些新的挑战，特别是大数据的领域，我们需要监控每一台主机后台统筹的指标，像CPU、内存、网络等，除了这些性能，应用层要监测的指标就更多了，简单的列举一下，比如说有一些缓存，前端的QPS，应用层可能需要和研发人员做一些运维紧密的配合，需要从应用的日志分析一些问题。

大家好，我是头一次来深圳和大家做分享，今天是讲精益应用性能管理，我们会有很多的主机，两年前不好意思打招呼，觉得我们系统里面，我们的主机数量，物理主机加上虚拟机还不到一百台，觉得不好意思好打招呼。过了半年以后，我们物理主机、虚拟机迅速超过了一百多台，这个在我们的互联网很多公司里，这是非常常见的现象，我们运维主机的数量，很全面在一百台以上甚至更多。
我们现在面临一些新的挑战，特别是大数据的领域，我们需要监控每一台主机后台统筹的指标，像CPU、内存、网络等，除了这些性能，应用层要监测的指标就更多了，简单的列举一下，比如说有一些缓存，前端的QPS，应用层可能需要和研发人员做一些运维紧密的配合，需要从应用的日志分析一些问题。
大数据时代，我们刚才简单列举了几个指标，大数据的时代，我们的架构发生了一些演进，我们的用户端会向移动端迁移，迁移最终的效果是什么？我们做运维都会比较头疼，移动端的数量，我们的日活可能上千万，至少成千上万，我们服务应用的客户端也是慢慢的提高了发展，我们的应用端也是在往后端的云上转移。
我们的互联网领域，产品的迭代速度是非常快的，我们在这个过程中，我们的监控能否跟上我们的产品迭代，我们的开发需求一直是在变的，我们后端的监控是不是能紧随着我们开发产品迭代的步伐，我们的技术架构也是越来越复杂，至少是不断的在往前演进，在演进的过程中延伸出我们的监控能不能跟上我们技术架构的变化。
如何监控我们的应用系统的性能？我们有很多的主机，成百上千台主机的基础指标，我们有成熟的监控手段，我们的CPU内存，我们的监控系统里要加一个RDB。我们应用以后的架构，我们如何监控我们的应用，后端有很多的服务和指标，其实都是需要去监控的，我们后台的架构可能会有数据库，我们会有NoSQL，我们的架构上可能做一些服务化的治理，我们会有大量的API调用，大量的API、远程的调用，我们的服务会往云端转移，这个过程中会带来监控的手段和以前有很大的不同，消息队列是我们架构里面比较常见的几个组件。
如何在我们的架构中对我们的应用进行持续的监控？精益化的性能管理的概念，我们做开发、做管理的同事可能比较熟悉，我们经常讲，我们是做敏捷开发，中间可能引入一些精益的流程，或者是敏捷式的流程，我们看其中比较有名的过程控制方法，这也是六西格玛的过程控制里比较重要的概念。
我们需要对我们的系统进行定义，我们首先要对我们的系统里面每一个指标进行度量，这个度量的前提是，要把我们要定义的东西首先全部拆解成一个一个具体的性能指标，比如说CDU网络，都会有比较成熟的指标，我们应用这块是不是有一些标准化的指标？我们度量之后就会对我们要做的管理进行分析，指标出来我们需要去分析，什么样的指标算是有问题？我们需要有标准化的分析方法。分析完之后需要有一个改善的过程，进行一些控制，不断改进、控制、度量分析的流程和迭代的持续演进。
我们很重要的理念，他没有更好的概念，我们能不能在下一步做得更好？我们说我们应用的性能是可以精确的度量。我们精细化的性能管理里，我们用APM的方式，怎么样持续的做数据改进和优化，监控这个东西，刚才说我们的应用系统，我们说不太好去监控，首先是在我们的应用里，需要监控的指标，首先要精确的度量出来，这是我们遇到的挑战，不同的应用系统是有不同的组件，我们怎么样把它标准化？通常的方式，被监控的技术组件的IO，从应用系统本身进行监控，应用本身就是我们系统里非常好的监控手段，所有后台的服务都是通过应用去调用的，我们能不能用我们的应用直接在运行的过程中，把监控和所有的指标都监控起来，这个是可行的。
我们传统的方法是监控基础的指标，CPU、内存，监控到这些，我们的应用哪里出现问题导致这样的结果。我们从应用层那边来看，只要给他可以度量的标准，哪里出问题，哪里可以被优化的。
我们再看一下我们怎么样做到这一点，从我们的应用层去完成自我的性能发现过程，这个过程我们简单的用代码来表示，我们要监控这个业务方法，比如说这个业务的方法叫做XXOO，我们里面有两个很简单的业务逻辑方法，我们怎么样监控这个业务方法和性能？做的方式很简单，总共分三步：一是在代码的块头插入，代码掉入执行时间打一个标注，把这个时间算进来。最后一步把这个指标上传到我们的系统里。我们也可以把这个异常信息捕捉起来自动上传上去，异常通常在我们应用优化里也是非常重要的关注点。
做完这个以后，是不是就比较完美了？显然不是的，我们运维的同学、开发的同学都要提出异议，运维会想说，这个东西必须在我们的业务代码里插入，运维首先是不能接受的，必须让研发干这个事情，我们的应用、我们的开发迭代，是不是要嵌入这个代码，需要规范的流程确保每个开发都有这样的监控意识把它管理，标准的代码放进去，在运维的层面上实施起来是不太可控的。
我想干的事情就是XXOO，插入和我用户代码无关的代码。我们有没有什么办法，这个过程我们想到这一点，我们发现问题的话，下一步我们要去改进这个流程，首先我们要去看到代码是标准的，作为的应用都可以数据库调用，Linuxe调用也不一样，我们可以对它调用的方法进行类似的操作，可以用非常标准的方式监控起来，我们能不能用自动化的方式完成这个过程？不需要开发人员手动的插入代码，这样看起来比较手动的代码。
拿Java举一个例子，这个过程对Java是有这样的机制，其他也有类似的方式实现。我们以Java举个例子，我们要干的事情是把标准的代码用一个标准的组件直接插到应用里，不需要业务的开发人员手动修改，我们Java里面有一个参数叫做JavaAgent，有一些做代码的诊断和运维的同学做一些类似的事情可能会用agent。实现了方式是他会有每个函数的入口，启动一个应用服务器还是我们自己的写的程序，最终都会用这个方法去启动除了这个函数以外，还有一个函数是Premain函数，这个函数我们可以用Instrumentatian动态加载的时候，我们执行的时候是我们JAM所看到的自解码，我们自己直接改掉就可以了，把那几行代码插到程序员写好的Classloader的代码里就可以自动实现。
我们用简单的代码给大家看看是怎么体现的，这个是我们原始的业务类的方法。怎么具体实现呢？我们用一个比较容易看的方式，做自解码修改的话，我们要干的事情是把自解码改掉，这个通常是需要非常了解自解码，事实上我们有一些第三方的框架是可以提供让我们以非常高级的方式，跟普通写代码的方式一样去修改他，写一个普通的业务代码很类似 ，可能会稍微麻烦一些。
这是一个Agent这个是一个单独的组件，这个不用修改任何的代码，我们在这里面，我们举简单的例子，我们确实是想监控XXOO的方法，让我们拿到XXOO的方法以后，我们用在标框的前面，在他的前面加上一个执行的时间，同样我们在后面插入一个执行的时间，我们就可以把执行的时间算出来。
为了看起来比较简单，我是用了比较简单的框架，这个是可以用于修改自解码，还有JavaASM，性能会比Java好很多，他的接口用起来比他更顶层一些，麻烦一些。这样的代码插进来以后，配合我们的Java的参数，我们配合Classloader，我们加入一个参数，以Agent的方式完成的代码的注入。运行的结果就是这样，XXOO是我们的业务代码产生的输出，后面就是我们刚才自动插进去的代码输出，这个我们把它稍微改一下上传到我们的监控系统里，我们的监控系统会监控日常、报警，所有的监控都可以做出来。
具体的过程刚才已经简单的介绍过了，首先我们通常实现自动化监控的时候，关键点是在刚才的自解码，在函数里我们是可以修改自解码，改完以后再返回给虚拟机，这是我们改过的代码，他其实看到的是我们改过的自解码，这个和我们的应用，在我们的开发过程中、应用里去写的效果是一样的，性能也是一样的。
我们需要去监控一些我们的系统里面对于web的顶替，我们会从它的请求到响应，他的响应时间是我们最关心的，这是用户直接感受到的时间，这个时间背后是可以分解，按他的组件去分解，在这个过程中我们和调用数据库，可能会调用各种各样的东西，任何一个环节出现性能问题，最终都可以占到我们响应时间的结果，这些组件都可以监控起来。
说到自动化，我们有一个很重要的，刚才是自动的嵌入，很显然我们是不能对所有的方法做嵌入操作，任何新的东西会影响到系统本身的性能，对所有的代码干这样的事情，最后的结果可能是不可预知的。我们最关心的是，我们的后台，我们常用的系统里，我们常用的架构里，我们最可能产生性能问题的是数据库，比如说压力比较大，后台的数据库任何的指标都可能会影响到整个应用和调用的时间。
比如说一般普通本机执行的操作，通常情况下，除非代码非常糟糕，产生性能问题的几率，像数据库，还有一个容易产生问题的地方，我们会调用云端的API，这个过程中，有网络的地方，都是一个潜在的风险点，MQ也是一样，掉线的话，大部分都是一些标准的地方。
再结合刚才的过程看一下我们对系统能监控哪些指标，我们监控的第一要素，我们要把他的应用系统里的所有组成部分分解，然后标准指标化进行度量，这个里面会监控响应时间，API调用，会有外部服务的时间，API调用的时间，包括会有一些IDC的调用，还有数据库的时间，整个组合起来是我们看到应用的响应时间。
对于外部应用，我们首先要对指标进行分解，我们的业务请求，访问到哪个url，这个是我们监控用户所关心最基本的单元，我们每一个请求，他的响应时间是什么样的，对应到后面的响应时间，如果发生什么问题，我们可以关注他后面问题出在数据库还是出在我们其他的组件上，我们希望看到应用方，我发现现在主机CPU有点高，内存有点高，到底是哪个组件出来问题？我们看最基础的应用。
我们看到一个比较慢的访问时间，这里有160多秒的请求访问，刚才说我们希望他到底去哪儿，首先可以看出来到底是哪几个后端的组件调用的方法占用系统的绝大部分，在这里，这个图上体现的是四个阶段，他是我们这里面对我们造成最大影响的部分。
刚才嵌码有一个地方没体现出来，每个方法监控起来，我们会把调用数输出，我们可以非常清晰的看到，调用对象是哪个函数。每个函数发现问题，对于开发人员还不够，有的时候，有些函数还要再调一调，我们可以做得更直接一点，我们是可以看到，他到底是在每个原文件的每个代码上的问题，所有的问题都是可能的。
我们现在在这个图上看到的是SQL的操作，它的SQL是什么样的？这个SQL我们可以现场抓出来，也可以对它进行一些其他的操作，比如说在现场的计划，优化细节可以看到的话，我们优化的结果可以看到是否规范。
这个是我们刚才说的比较简单的方式，后台可能很多的服务，可以通过API和其他的服务框架，做一些应用之间的调用链，前端的应用发生问题的时候里有的时候是由于后端的服务产生的问题导致前端，我们监控到前端，如果不监控后端还是很麻烦的，后台提示大家的节点，排查的时候能不能自动的把后端慢的过程也输出出来。比如说我们在这个地方看到一个前台的应用情况，我们追踪进去，发现后端的某个API调用是URL，这个我们是希望在这个地方，我们在这个地方自动关联过去的话，我们会看到他刚才这个API调用是由于后端提供服务的Sever出现了问题，他的SQL直接抓到，他的响应时间很短，问题在于他是执行了，在同一个云端他执行了1900多次，这个不慢就奇怪了，这个是通过自动嵌码的方式把前后端可以串联起来去帮助我们去做快速的分析、定位、诊断，基本上可以现场做出来。
谢谢大家的聆听和关注，我们是听云，这些都是用我们运营的互联网公司，谢谢大家。