全栈溯源、mAPM、金融性能、Oracle VS. MySQL:看 APM 技术专场有哪些干货

  • 听云

2017 年 4 月 23 日

话题:Oracle数据库MySQL语言 & 开发架构文化 & 方法

在日益复杂的应用环境中,网络、移动端、浏览器端、服务端的性能问题种类繁多,如何精准的定位问题根源,并留住用户是关键问题。尤其是云计算平台的普及使用,更是对应用性能的追踪和优化提出了新的拷问。在此前提下,听云提出新一代 APM 方案,通过全栈溯源的技术来追踪并采集用户数据,直接定位到代码行级,快速给出定制化的解决办法。

在本月的 QCon 北京听云专场上,来自听云、光大银行和搜狐畅游的技术讲师们介绍了新的 APM 技术突破,传统企业在金融应用性能优化方面的实践经验,以及对 Oracle 和 MySQL 优化的一些感悟内容,希望能给读者带来真正的思路上的帮助。由于篇幅有限,仅作重点内容介绍。欢迎留言。

以 MQ 为例的全栈溯源技术

当前,异步模型被广泛使用,MQ 作为异步消息处理的一种实现,在企业应用中被广泛采用。Consumer 对消息的处理能力,反应了消息中间件的性能好坏,杨金全的分享主要围绕如何透明的追踪消息由产生到被消费的整个处理过程,实现异步场景下的全栈溯源。

MQ 的使用场景一般就是异步通信、异构解耦、过载保护和数据流处理,但是 MQ 在监控异步消息处理的时候也遇到了一些困境,例如部署架构不清晰,没有业务数据,无法快速定位队列积压原因。也正是基于这样的问题,听云研发团队考虑做异步场景下消息的追踪 Tracer,这就需要考虑 MQ 协议,常用的协议这里也列举出来,AMQP 协议的特点是可靠、通用;MQTT 协议的特点是格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统;STOMP 协议的特点是命令模式,非 topic/queue 模式;XMPP 协议的特点是通用公开、兼容性强、可扩展、安全性高,但 XML 编码格式占用带宽大。

通过这些方法可以追踪信息,从消息中间件获取性能数据,了解对性能产生的影响。那么如何来定义衡量对于 RabbitMQ 业务监控的指标呢?以往是可以通过看日志的方式,但是现在 APM 技术可以很好地解决这个问题。

因为 APM 技术可以在测试阶段,不管是在开发测试阶段,还是在实验室测试环境下,都可以发现和定位性能问题以及出现故障的原因。并且在应用性能监测过程中帮助产品实现应用运营,在复杂的生产环境中预测潜在的性能问题,在发布产品之后仍然可以持续监测下去。这里面,杨金全也介绍了 RabbitMQ 案例,感兴趣的可以下载 PDF 文件详细查看。

光大银行系统应用优化实践

光大银行信息科技部系统运维中心高级经理彭晓,在现场分享了光大银行建立的全方位应用监控体系和应用系统容量管理机制,以及通过应用监控和生产系统容量分析来实现应用系统性能问题预警,驱动应用系统的架构、交易处理模式优化,提升应用系统在大交易量、高并发方面的处理能力与效率。

彭晓在开始阶段也介绍了光大银行在应用性能实践方面的挑战,但是这里偏重于介绍光大银行在应用性能调优关联因素调优实践的内容,因为这样的过程可能对用户来说更有借鉴意义。

> 基础设施(网络优化)

电子支付交易路径优化前,专线接入的商户,存在网络路径太长、跨越安全域多、节点多且 NAT 地址转换复杂,给支付成功率提升和故障诊断排错带来困难;优化之后,减少电子支付交易途径网络区域和节点;通过技术优化,解决商户快捷交易会话不拆除和源端口复用问题;支付掉单率降低 50%;最重要的是,多互联网出口改造优化带来了很高的效率提升。

> 基础设施(存储优化)

IO 条带化提升效率,同时数据分级应用,分级存储。

> 操作系统

从操作的维度对只读数据,读写数据,静态数据的处理。对只读数据,通过数据库的复制技术,建立只读数据库,分散联机数据库的运行压力,在应用交易级别实现读写分离。这一部分特点读写访问量比较大,事务一致性要求高,一般采取传统关系数据库加高端存储处理方式,静态一般是参数的配置的数据,它的修改的频度低一点,访问并发量大,对此一般采用内存数据库方技术,在应用服务器端缓存数据来提高处理性能。总体方法就是去除热点,分散压力。

依据运行经验,制定 OS 参数标准。不限制应用使用 OS 资源,系统的资源就是给应用来使用。不采用更改 OS 原有调度方式的参数,来确定系统的稳定性。

> 中间件

在中间件方面,依据运行经验制定 MW 参数标准。具体两个标准,第一个中间件的参数设置从应用需求出发,中间件资源一次配置到位,避免自动调整带来的冲击。在光大系统层,中间件的参数自动拓展,在拓展当中带来运营系统不稳定,所以 IT 部门尽量一次性配置到位,避免自动调整带来冲击。

> 应用及应用间关联

与应用相关的关联较多的是银行支付系统,主要采取的措施包括服务的拆分,包括对于支付网关的分离部署,包括对于较大的第三的网关进行独立的布什。负载均衡,这个是比较常用的,通过实现负载均衡多个机制。

  • 服务拆分:支付网关分离部署,将支付宝接入所需网关服务独立部署,采用专线接入模式;
  • 负载均衡:支付网关实现负载均衡多活机制,通过 F5 实现压力负载;
  • 硬件加速:将软件加解密升级为硬件加解密,实现加解密功能拆分,降低服务器资源使用;
  • 负载均衡:总线系统实现负载均衡多活机制;
  • 异步提交:应用日志支持同异步两种提交方式,应用日志文件异步提交、应用日志数据库异步批量提交;支持在线实施策略调整;
  • 存储转发:针对时效性低、重要性高的业务设置存储转发策略,将业务要素先存储,后转发
  • 服务分组:按照后台系统、业务特点进行服务分组,降低系统间不同业务之间相互影响;
  • 流量控制:多维度限流(可按重要系统、重要业务等方式设置限流策略);
  • 在线生效:动态限流策略调整;

mAPM 的性能监测实践

杨凯老师在这里介绍了 APM 中的一个监控技术:NSURLProtocol,以及使用它的基本步骤和一些应用场景。场景包括:a、实现本地资源的管理,例如图片;b、通过特殊 URL 实现 JS 到 OC 的调用,但现在有 JavaScriptCore 了,这种方式过时了;c、对内容过滤、审核;d、配合 UIWebview 做个特殊的浏览器。

URL Loading System 的机制,非常灵活,在某种程度上相当于程序内部的一个代理。杨凯老师详细介绍了它的优缺点内容:

优点:拦截所有 URL 的加载,当然 NSURLSession 要特殊处理一下,尤其是 UIWebview 的网络,只能用这种方式拦截。

坑 1:对缓存的处理是个麻烦,而且工作量也很大。

坑 2:不要改变当前线程和 runLoopMode,否则那边有可能一直等不到数据,如果那边用。

坑 3:startLoading 会重入,很奇怪的,不知道什么原因。

还有一个缺点:效率低,正因为这个缺点,需要第二个方案来弥补。

另外一个监控工具是 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 也都是很不错的选择,感兴趣的可以下载杨老师的演讲 PDF 内容

Oracle 和 MySQL 的性能优化感悟

杨建荣主要从事 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 这两方面工作的人,该有什么样的职业规划呢?他的建议是:

  • 技术值钱,钱不值钱
  • 选择比努力重要,选择比努力难得多
  • 最怕一生碌碌无为,还说平凡难能可贵
  • 小狗和幸福的故事
  • 以退为进天地宽
  • 做有价值的事情。复杂的事情简单做,简单的事情重复做,重复的事情用心做

更多详细内容高,可以下载杨建荣的演讲 PDF 内容

Oracle数据库MySQL语言 & 开发架构文化 & 方法