作为架构师，为什么要性能调优？
开场白
大家好，我有一个朋友，有一次他跟我说，他们公司的系统从来没有经过性能调优，功能测试完成后就上线了，线上也没有出现过什么性能问题呀，那为什么很多系统都要去做性能调优呢？ 当时我就回答了他一句，如果你们公司做的是大型的互联网网站，不做系统性能优化就上线，试试看会是什么情况。如果是你，你会怎么回答呢？今天，我们就从这个话题聊起，只要大量用户参与的系统，我们必然要做性能优化。当然要做好我们还有很长的路要走，希望能跟你一起弄明白这几个问题：我们为什么要做性能调优？什么时候开始做？做性能调优是不是有标准可参考？
为什么要做性能调优
一款线上产品如果没有经过性能测试，那它就好比是一颗定时炸弹，你不知道它什么时候会出现问题，你也不清楚它能承受的极限在哪儿。
有些性能问题是时间累积慢慢产生的，到了一定时间自然就爆炸了；而更多的性能问题是由访问量的波动导致的，例如，搞个活动或者公司产品用户量突然上升；当然也有可能是一款产品上线后就半死不活，一直没有大访问量，所以还没有引发这颗定时炸弹。 现在假设你的系统要做一次活动，产品经理或者老板告诉你预计有几十万的用户访问量，询问系统能否承受得住这次活动的压力。如果你不清楚自己系统的性能情况，也只能战战兢兢地回答老板，有可能大概没问题吧。 所以，要不要做性能调优，这个问题其实很好回答。所有的系统在开发完之后，多多少少都会有性能问题，我们首先要做的就是想办法把问题暴露出来，例如进行压力测试、模拟可能的操作场景等等，再通过性能调优去解决这些问题。 系统响应就是体现系统性能最直接的一个参考因素。 那如果系统在线上没有出现响应问题，我们是不是就不用去做性能优化了呢？讲个真实的故事。 曾经我的前前东家系统研发部门来了一位大神，为什么叫他大神，因为在他来公司的一年时间里，他只做了一件事情，就是把服务器的数量缩减到了原来的一半，系统的性能指标，反而还提升了。 好的系统性能调优不仅仅可以提高系统的性能，还能为公司节省资源。这也是我们做性能调优的最直接的目的。
什么时候开始介入调优
解决了为什么要做性能优化的问题，那么新的问题就来了：如果需要对系统做一次全面的性能监测和优化，我们从什么时候开始介入性能调优呢？是不是越早介入越好？ 其实，在项目开发的初期，我们没有必要过于在意性能优化，这样反而会让我们疲于性能优化，不仅不会给系统性能带来提升，还会影响到开发进度，甚至获得相反的效果，给系统带来新的问题。 我们只需要在代码层面保证有效的编码，比如，多注意编码规范，可以参考阿里的开发规范来约束我们开发，减少磁盘 I/O 操作、降低竞争锁的使用，以及使用高效的算法等等。遇到比较复杂的业务，我们可以充分利用设计模式来优化业务代码。例如，发送各种邮件，短信，微信，钉钉，我们可以用装饰模式和策略模式去设计这个业务。 在系统编码完成之后，我们就可以对系统进行性能测试了。这时候，我们在提供的参考平台上进行压测，通过性能分析、统计工具来统计各项性能指标，看是否在预期范围之内。 在项目成功上线后，我们还需要根据线上的实际情况，依照日志监控以及性能统计日志，来观测系统性能问题，一旦发现问题，就要对日志进行分析并及时修复问题。
| 总结 |
|---|
- 前期不用考虑性能优化
- 多做一些编码级别的优化
- 使用阿里规范来约束自己团队整体的开发水平
- 复杂的业务多用设计模式来设计开发，比如单例设计模式，策略设计模式，观察者模式。
- 做好日志的监控（可以在架构设计的时候，记录每个调用的追踪id，这样可以有利于排查）
- 做好各种异常的处理
有哪些参考因素可以体现系统的性能
在这里我已经介绍了项目研发的各个阶段性能调优是如何介入的，多次讲到了性能指标，那么性能指标到底有哪些呢？ 在我们了解性能指标之前，我们先来了解下哪些计算机资源会成为系统的性能瓶颈。
木桶原理
木桶定律是讲一只水桶能装多少水取决于它最短的那块木板 。一只木桶想盛满水，必须每块木板都一样平齐且无破损，如果这只桶的木板中有一块不齐或者某块木板下面有破洞，这只桶就无法盛满水。
我们把系统的整体性能比作是一个大的木桶那么他的组成部分就是：
整体的系统性能要依靠 CPU，内存，磁盘IO，网络，异常，数据库，锁竞争（线程上下文切换）
CPU：有的应用需要大量计算，他们会长时间、不间断地占用 CPU 资源，导致其他资源无法争夺到 CPU 而响应缓慢，从而带来系统性能问题。例如，代码递归导致的无限循环，正则表达式引起的回溯，JVM 频繁的 FULL GC，以及多线程编程造成的大量上下文切换等，这些都有可能导致 CPU 资源繁忙。
内存：Java 程序一般通过 JVM 对内存进行分配管理，主要是用 JVM 中的堆内存来存储 Java 创建的对象。系统堆内存的读写速度非常快，所以基本不存在读写性能瓶颈。但是由于内存成本要比磁盘高，相比磁盘，内存的存储空间又非常有限。所以当内存空间被占满，对象无法回收时，就会导致内存溢出、内存泄露等问题。
磁盘 I/O：磁盘相比内存来说，存储空间要大很多，但磁盘 I/O 读写的速度要比内存慢，虽然目前引入的 SSD 固态硬盘已经有所优化，但仍然无法与内存的读写速度相提并论。
网络：网络对于系统性能来说，也起着至关重要的作用。如果你购买过云服务，一定经历过，选择网络带宽大小这一环节。带宽过低的话，对于传输数据比较大，或者是并发量比较大的系统，网络就很容易成为性能瓶颈。
异常：Java 应用中，抛出异常需要构建异常栈，对异常进行捕获和处理，这个过程非常消耗系统性能。如果在高并发的情况下引发异常，持续地进行异常处理，那么系统的性能就会明显地受到影响。
数据库：大部分系统都会用到数据库，而数据库的操作往往是涉及到磁盘 I/O 的读写。大量的数据库读写操作，会导致磁盘 I/O 性能瓶颈，进而导致数据库操作的延迟性。对于有大量数据库读写操作的系统来说，数据库的性能优化是整个系统的核心。
锁竞争：在并发编程中，我们经常会需要多个线程，共享读写操作同一个资源，这个时候为了保持数据的原子性（即保证这个共享资源在一个线程写的时候，不被另一个线程修改），我们就会用到锁。锁的使用可能会带来上下文切换，从而给系统带来性能开销。
回顾我自己的项目经验，有电商系统、支付系统，智能家居系统。系统每天都要承受各种大量的访问压力，所以我对系统的性能要求非常苛刻。除了通过观察以上指标来确定系统性能的好坏，还需要在更新迭代中，充分保障系统的稳定性。 这里，给你延伸一个方法，就是将迭代之前版本的系统性能指标作为参考标准，通过自动化性能测试，校验迭代发版之后的系统性能是否出现异常，这里就不仅仅是比较吞吐量、响应时间、负载能力等直接指标了，还需要比较系统资源的 CPU 占用率、内存使用率、磁盘 I/O、网络 I/O 等几项间接指标的变化。
在这里给大家留一个思考题？
除了以上我给出的性能指标你是否还有其他的参考方式？欢迎给我留言。
本文中版权归独秀天狼团队所有，转载请标注清楚。