程序员必须练就的「性能调优」组合拳【1】

性能调优，程序员转型架构师的拦路虎【1】

在【 程序员必须掌握的性能调优 XYZ 】这篇文章中，老兵哥结合个人经历解释了程序员往架构师方向发展时为什么要跨越性能调优这一关，这是我们建立流程化、结构化、系统化的思维的契机。另外，老兵哥还介绍了从 X、Y、Z 三个维度优化性能的思路。接下来，我们将从 X 维度来谈谈优化业务交互设计的思路。

• X 维度，即业务维度，技术始终是服务业务的，任何技术问题的原点就是业务需求。在启动技术层面的性能优化之前，我们有必要先审视一下业务流程是否合理，交互设计上有没有可以优化的空间等。
• Y 维度，待业务维度优化完毕，接下来就是审视技术在实现当前业务流程或交互设计的全链路上有没有可优化的地方，即 HTTP 请求处理全流程，从浏览器到应用容器，再到 Spring、Hibernate、数据库等。
• Z 维度，除了沿着 HTTP 请求的横向链路，我们还要审视支持应用系统的纵向技术栈，从上到下包括 JVM、操作系统和硬件等，这是整套应用系统运行的环境，许多性能问题都跟运行环境存在关系。

X 维度本身超出了技术范畴，但为了更好地服务业务，技术人也有必要懂得一些基础的业务优化思路。如果只知道埋头赶路，不知道抬头看天，那我们技术人很容易做了费力不讨好的事情，例如：某些性能瓶颈是由于业务流程设计不合理导致的，在业务流程优化完善之前，我们仅仅从技术视角去优化改善，极有可能事倍功半。具体说来，哪些业务优化思路是值得我们借鉴实践的呢？我分享几点经验做引子。

让客户端分担部分计算存储任务。互联网应用最显著的特点就是用户基数非常大，每项业务操作本身的计算量可能不大，但是乘上用户量之后情况就完全不一样了，为了保障业务正常高效运转，我们就要投入更多服务器和带宽资源。如果资源投入跟不上业务量的增长，那么系统性能就会变差，用户操作就会超时或失败，用户体验就会变差，最终导致业务受损。有没有办法在不增加资源投入的情况下来改善系统性能呢？如果把用户的终端（手机或电脑等）也纳入到系统范畴，那么把某些适合的任务放到客户端计算是缓解服务端资源的有效办法。

具体有哪些任务适合交给客户端处理呢？数据合法性的初步验证、数据的加工转换、数据呈现形式变换等等，例如在注册登录过程中，客户端可以对用户填写的信息做格式层面的校验，如果不符合要求可以直接给出提示信息让用户重新填写，这样就免去了将信息发送至服务器的资源消耗。在现在流行的人脸或声纹验证身份的场景下，客户端可以直接提取照片或声音的特征码发往服务器端做校验，而不是把照片或声音文件直接发送过去。还有就是对已呈现数据的排序或展示转换上，客户端也完全可以胜任。现在的客户端计算存储能力都很强大，关键是我们要识别出哪些任务适合在客户端运行，这是提升性能一个思路方向。

除此之外，优化交互设计是提升性能非常有效的途径。如果交互设计不合理，那就容易产生许多无效的操作，这就是对资源最大的浪费。举一个非常普遍的场景为例，不管何种类型的业务，都会存在耗时较长的操作，比如将某批任务分派给许多人，分配时要综合考虑任务和执行者的匹配度，这个匹配过程的耗时跟任务和执行者的数量成正比，我们习惯性做法就是提交操作指令后阻塞轮询进度直至完成，而轮询会导致大量无效的查询请求，尤其在海量用户的情况下，这就是一场 DDos 攻击，很容易自己就把自己给搞死了。

化解这种问题的关键就是优化交互，把阻塞轮询改成异步通知，批量操作指令提交之后就不再轮询进度了，而是等待服务器端的进度更新通知，这样就避免了大量无效的查询请求。当然，业务流程优化依赖对业务的深刻理解，这更多是产品的职责，但我们技术也要懂得常见业务模式对性能的影响。今天先聊到这里，下一篇我们将从 Y 技术维度来看看如何优化应用的性能。

关注「 IT老兵哥 」，赋能程序人生！近期热评系列《 程序员必须懂的架构师入门课 》：

1. 程序员为什么必须要懂架构？
2. 架构到底是什么，你知道吗？
3. 架构都有哪些，我该怎么选？
4. 架构师都干什么，你知道吗？
5. 练就哪些技能才胜任架构师？
6. 怎样才能搞定上下游的客户？
7. 如何从开发岗转型做架构师？