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

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

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

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

本文原创地址：https://www.linuxprobe.com/app-system-optimization.html编辑：public，审核员：暂无