在日益复杂的应用环境中，网络、移动端、浏览器端、服务端的性能问题种类繁多，如何精准的定位问题根源，并留住用户是关键问题。尤其是云计算平台的普及使用，更是对应用性能的追踪和优化提出了新的拷问。在此前提下，听云提出新一代APM方案，通过全栈溯源的技术来追踪并采集用户数据，直接定位到代码行级，快速给出定制化的解决办法。
在本月的QCon北京听云专场上，来自听云、光大银行和搜狐畅游的技术讲师们介绍了新的APM技术突破，传统企业在金融应用性能优化方面的实践经验，以及对Oracle和MySQL优化的一些感悟内容，希望能给读者带来真正的思路上的帮助。由于篇幅有限，仅作重点内容介绍。欢迎留言。
当前，异步模型被广泛使用，MQ 作为异步消息处理的一种实现，在企业应用中被广泛采用。Consumer 对消息的处理能力，反应了消息中间件的性能好坏，杨金全的分享主要围绕如何透明的追踪消息由产生到被消费的整个处理过程，实现异步场景下的全栈溯源。
MQ的使用场景一般就是异步通信、异构解耦、过载保护和数据流处理，但是MQ在监控异步消息处理的时候也遇到了一些困境，例如部署架构不清晰，没有业务数据，无法快速定位队列积压原因。也正是基于这样的问题，听云研发团队考虑做异步场景下消息的追踪Tracer，这就需要考虑MQ协议，常用的协议这里也列举出来，AMQP协议的特点是可靠、通用；MQTT协议的特点是格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统；STOMP协议的特点是命令模式，非topic/queue模式；XMPP协议的特点是通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大。
通过这些方法可以追踪信息，从消息中间件获取性能数据，了解对性能产生的影响。那么如何来定义衡量对于RabbitMQ业务监控的指标呢？以往是可以通过看日志的方式，但是现在APM技术可以很好地解决这个问题。
因为APM技术可以在测试阶段，不管是在开发测试阶段，还是在实验室测试环境下，都可以发现和定位性能问题以及出现故障的原因。并且在应用性能监测过程中帮助产品实现应用运营，在复杂的生产环境中预测潜在的性能问题，在发布产品之后仍然可以持续监测下去。这里面，杨金全也介绍了RabbitMQ案例。
光大银行信息科技部系统运维中心高级经理彭晓，在现场分享了光大银行建立的全方位应用监控体系和应用系统容量管理机制，以及通过应用监控和生产系统容量分析来实现应用系统性能问题预警，驱动应用系统的架构、交易处理模式优化，提升应用系统在大交易量、高并发方面的处理能力与效率。彭晓在开始阶段也介绍了光大银行在应用性能实践方面的挑战，但是这里偏重于介绍光大银行在应用性能调优关联因素调优实践的内容，因为这样的过程可能对用户来说更有借鉴意义。
电子支付交易路径优化前，专线接入的商户，存在网络路径太长、跨越安全域多、节点多且NAT地址转换复杂，给支付成功率提升和故障诊断排错带来困难；优化之后，减少电子支付交易途径网络区域和节点；通过技术优化，解决商户快捷交易会话不拆除和源端口复用问题；支付掉单率降低50%；最重要的是，多互联网出口改造优化带来了很高的效率提升。
IO 条带化提升效率，同时数据分级应用，分级存储。
从操作的维度对只读数据，读写数据，静态数据的处理。对只读数据，通过数据库的复制技术，建立只读数据库，分散联机数据库的运行压力，在应用交易级别实现读写分离。这一部分特点读写访问量比较大，事务一致性要求高，一般采取传统关系数据库加高端存储处理方式，静态一般是参数的配置的数据，它的修改的频度低一点，访问并发量大，对此一般采用内存数据库方技术，在应用服务器端缓存数据来提高处理性能。总体方法就是去除热点，分散压力。
依据运行经验，制定OS参数标准。不限制应用使用OS资源，系统的资源就是给应用来使用。不采用更改OS原有调度方式的参数，来确定系统的稳定性。
在中间件方面，依据运行经验制定MW参数标准。具体两个标准，第一个中间件的参数设置从应用需求出发，中间件资源一次配置到位，避免自动调整带来的冲击。在光大系统层，中间件的参数自动拓展，在拓展当中带来运营系统不稳定，所以IT部门尽量一次性配置到位，避免自动调整带来冲击。
与应用相关的关联较多的是银行支付系统，主要采取的措施包括服务的拆分，包括对于支付网关的分离部署，包括对于较大的第三的网关进行独立的布什。负载均衡，这个是比较常用的，通过实现负载均衡多个机制。
服务拆分：支付网关分离部署，将支付宝接入所需网关服务独立部署，采用专线接入模式；
负载均衡：支付网关实现负载均衡多活机制，通过F5实现压力负载；
硬件加速：将软件加解密升级为硬件加解密，实现加解密功能拆分，降低服务器资源使用；
负载均衡：总线系统实现负载均衡多活机制；
异步提交：应用日志支持同异步两种提交方式，应用日志文件异步提交、应用日志数据库异步批量提交；支持在线实施策略调整；
存储转发：针对时效性低、重要性高的业务设置存储转发策略，将业务要素先存储，后转发
服务分组：按照后台系统、业务特点进行服务分组，降低系统间不同业务之间相互影响；
流量控制：多维度限流（可按重要系统、重要业务等方式设置限流策略）；
在线生效：动态限流策略调整；
杨凯老师在这里介绍了APM中的一个监控技术：NSURLProtocol，以及使用它的基本步骤和一些应用场景。场景包括：a、实现本地资源的管理，例如图片；b、通过特殊URL实现JS到OC的调用，但现在有JavaScriptCore了，这种方式过时了；c、对内容过滤、审核；d、配合UIWebview做个特殊的浏览器。
URL Loading System的机制，非常灵活，在某种程度上相当于程序内部的一个代理。杨凯老师详细介绍了它的优缺点内容：
优点：拦截所有URL的加载，当然NSURLSession要特殊处理一下，尤其是UIWebview的网络，只能用这种方式拦截。
还有一个缺点：效率低，正因为这个缺点，需要第二个方案来弥补。
另外一个监控工具是method swizzling，Swizzle也被称为OC上的hook，其实，只要能把你的代码挂到调用链上，都算是hook。这里说的是method swizzle，原理就是利用OC的运行时特性，操作类的定义信息。OC的灵活是因为它的消息机制，用OC的方式调用函数，其实是发出一个消息，至于这个消息由那个函数处理，需要查表，method swizzle就是修改了这个表。消息就是所谓的Selector。
呼叫selectorA，最后执行IMPa，假如要拦截selectorC这个消息，经典做法是增加一个消息selectorN，然后它与selectorC互换IMP。
method swizzling的优点是不会循环调用，而且速度快，不需要查表，直接函数指针。实际上，这个工具现在有个新的名字，叫Method Hook。
除了上面介绍的两个工具之外，还有isa swizzling，和isa swizzling＋NSProxy也都是很不错的选择。
杨建荣主要从事Oracle方面的工作，也会涉及到MySQL相关内容，所以切身体会来讲讲这两者之间的优化对比。
Oracle和MySQL的技术矩阵
数据访问的模式对比
性能优化的基石
性能优化和系统演进策略
数据库参数的版本变化
在数据库连接上，Oracle和MySQL还是有很大的差别，通过这个可以反映出架构的差别。还有性能优化的基石，首先保证不丢数据，业务能够持续运行的前提下，这个优化才能有意义。比如说优化的再好，Oracle优化从一个小时优化到一秒，但前提是数据库不丢数据才有意义。
关于监控和优化的方式，基本上是用Zabbix+Orabbix的组合，优化之后在此基础上做比较细的完善。其次就是性能测试工具有两个版本，一个是Sysbench，一个是swingbench。Sysbench支持Oracle和MySQL，小事务，关注TPS，QPS，swingbench只支持Oracle，模拟订单业务。Sysbench有图形化，图形化显示好一些，swingbench图形质差一些。文本命令的方式去支持的。当然实际上这个Sysbench已经开源了，所以发展的好一些。swingbench也算是个人的一个占比，而Sysbench支持的比较好一些，这也是两个工具的差别所在。
最后，杨建荣也谈到了从事MySQL和Oracle这两方面工作的人，该有什么样的职业规划呢？他的建议是：
公众号对话框回复：PPT，获取QCon北京2017PPT合集
正式演讲从9分30秒开始~
