系统架构如何进行性能优化？

对于营业系统的性能优化，我原来系统的谈过剖析和诊断的思绪，今天再谈下营业系统性能优化内里我们常见的一些思索和剖析系统性能问题的方式。

上线前的性能测试是否有用？有时刻人人可能以为新鲜，为何我们系统再上线前都做了性能测试，为何上线后照样会泛起系统性能问题。那么我们可以思考下现实上我们上线前性能测试可能存在的一些无法真实模拟生产环境的地方，详细为：

1. 硬件能否完全模拟真实环境？最好的性能测试往往是直接在搭建完成的生产环境进行。

2. 数据量能否模拟现实场景？真实场景往往是多个营业表都已经存在大数据量的积累而非空表。

3. 并发能否模拟真实场景？一个是并发需要录制复合营业场景，一个是并发量大时刻需要多台压测机。

而现实上我们在做性能测试的时刻以上几个点都很难真正做到，因此要想完全模拟出生产真实环境是相当难题的，这也导致了许多性能问题是在真正上线后才发现。

系统自己水平弹性扩展是否完全解决性能问题？第二个点也是我们经常谈的对照多的点，就是我们的营业系统在进行架构设计的时刻，稀奇是面临非功效性需求，我们都谈判到系统自己的数据库，中央件都接纳了集群手艺，能够做到弹性水平扩展。那么这种弹性水平扩展能力是否又真正解决了性能问题？

现实上我们看到对于数据库往往很难真正做到无限的弹性水平扩展，纵然对于Oracle RAC集群往往也是最多扩展到单点的2到3倍性能。对于应用集群往往可以做到弹性水平扩展，当前手艺也对照成熟。

当中央件能够做到完全弹性扩展的时刻，现实上仍然可能存在性能问题，即随着我们系统的运行和营业数据量的不停积累增值。现实上你可以看到往往非并发状态下的单用户接见自己就很慢，而不是说并发上来后满。因此也是我们常说的要给点，即：

单点接见性能正常的时刻可以扩展集群来应对大并发状态下的同时接见

单点接见自己性能就有问题的时刻，要优先优化单节点接见性能

营业系统性能诊断的分类

对于营业系统性能诊断，若是从静态角度我们可以思考从以下三个方面进行分类

操作系统和存储层面中央件层面（包罗了数据库，应用服务器中央件）软件层面（包罗了数据库SQL和存储历程，逻辑层，前端展现层等）那么一个营业系统应用功效泛起问题了，我们固然也可以从动态层面来看现实一个应用请求从挪用最先事实经由了哪些代码和硬件基础设施，通太过段方式来定位和查询问题。

好比我们常见的就是一个查询功效若是泛起问题了，首先就是找到这个查询功效对应的SQL语句在后台查询是否很慢，若是这个SQL自己就慢，那么就要优化优化SQL语句。若是SQL自己快然则查询慢，那就要看下是否是前端性能问题或者集群问题等。

软件代码的问题往往是最不能忽视的一个性能问题点对于营业系统性能问题，我们经常想到的就是要扩展数据库的硬件性能，好比扩展CPU和内存，扩展集群，然则现实上可以看到许多应用的性能问题并不是硬件性能导致的，而是由于软件代码性能引起的。对于软件代码常见的性能问题我在以往的博客文章内里也谈过到，对照典型的包罗了。

1. 循环中初始化大的结构工具，数据库毗邻等

2. 资源不释放导致的内存泄露等

3. 没有基于场景需求来适度通过缓存等方式提升性能

4. 长周期事务处置花费资源

5. 处置某一个营业场景或问题的时刻，没有选择最优的数据结构或算法

以上都是常见的一些软件代码性能问题点，而这些往往需要通过我们进行Code Review或代码评审的方式才气够发现出来。因此若是要做周全的性能优化，对于软件代码的性能问题排查是必须的。

通过IT资源监控或APM应用工具来发现性能问题对于性能问题的发现一样平常有两条路径，一个就是通过我们IT资源的监控，APM的性能监控和预警来提前发现性能问题，一个是通过营业用户在使用历程中的反馈来发现性能问题。

而随着DevOps和自动化运维的思绪推进，我们加倍希望是通过APM等工具自动监控来发现性能问题，对于APM工具最大的利益就是可以进行服务链间和全链路的性能剖析，利便我们发现性能问题事实发生在那里。好比我们提交一个表单很慢，通过APM剖析我们很容易发现事实是挪用哪个营业服务慢，或者是处置哪个SQL语句慢。这样可以极大的提升我们性能问题剖析诊断的效率。