最近遇到一个互联网金融应用系统的性能问题,看了开发的优化方案,觉得还不够深入。结合之前看到一些互联网企业分享的方案,今天从运维角度整理一下比较理想的应用系统性能优化思路。

先列一个传统应用架构的几个组成部份:

上面的架构容易出现几个常见问题:

1、应用内部服务APP的服务承载的交易服务过多,从交易看是紧耦合的;

2、源交易应用到目标应用之间经过总线、多个过程系统,最终才到目标系统,任一环节出问题都将影响这支交易的性能;

3、从应用来看,高并发的情况下前端容易出现并发数过高导致的异常,后端DB数据处理容易因前端过多交易导致的DB连接数超限;

4、关联系统,尤其是总线系统如采用同步方式容易导致总线系统瘫痪,最终导致影响企业其它应用系统;

所以,优化后的架构大致如下:

主要的几点思路如下:

1、应用拆分:逻辑上分析业务主流程,将分支交易进行分离,按业务功能拆分独立的服务;物理上将独立的服务进行分离,独立部署,出现问题后可以快速采取措施进行隔离或扩容。

2、服务或系统交互解耦:如WEB到逻辑服务前加队列层,减少前端放开流量导致后端处理能力跟不上的问题;数据库前加上缓存层,减少数据库的并发压力。

3、减少总线节点服务的依赖:由多节点组成的逻辑交互改为端对端的访问方式,一方面减少影响交易的因素,另一方面减少自身性能问题影响其它应用系统。

4、增加异步访问机制:同步的机制在性能出现问题时,会在短时间花完最大连接数,哪怕这个最大并发数是正常情况下的10倍。这方面可以直接改异步通讯,也可以引入一些队列工具实现。

5、多层次的缓存:缓存的引入可以多层次,从前端、应用内部、数据库等,比如:前端页面可以利用缓存技术减少页面刷新,这方面可以采用网络工具解决;数据库前可以采用REDIS等;应用自身同样可以用缓存代替数据库的读操作;

6、数据库优化:1)架构上:拆库、在线库与历史库分离、分布式数据库、读写分离、非关系型数据库。比如:第1点应用拆分后,则可以按业务拆库;分布式数据库实现数据分片读写等等。2)编码上:SQL优化、索引新增、数据定时清理,这个优化方式最快,最容易出效果;减少数据库访问次数、减少数据库一次返回的结果集;

7、前端限流、削峰机制,前端系统因为逻辑简单往往可以支持更多请求,但后端系统则不同。所以需要前端系统做交易并发控制,并通过一些前端交互设计减少客户的本验影响;

8、基础设施支持快速扩容:支持弹性扩容(第1点系统拆分独立部署很重要,可以减少扩容复杂性)。

9、服务降级:重要服务重点保障,次要服务有损保障,紧急情况下进行降级。

另外,做运维,当然要从运维角度进行一些辅助性工作,比如:

  • 灰度发布
  • 性能监控、业务监控
  • 性能基线的建立
  • 性能分析,用数据分析抓典型的性能瓶径并督促优化

最后,方案看起来挺美好,但放在实际的情况下,阻力可能很大,甚至根本没法实施,因为这些思路对开发团队依赖比较大。

但梦想还是要有,说不定哪天就实现了,比如,哪天开发团队的老板觉得性能和业务功能实现同等重要的时候。

作者:彭华盛

文章来自微信公众号:运维之路

原文来自:http://www.yunweipai.com/archives/12900.html

本文地址:http://www.linuxprobe.com/app-system-optimization.html编辑员:华世发,审核员:逄增宝