接口性能优化怎么做？

文章目录

为什么要做接口性能优化
怎样做接口性能优化，思路是怎样的
- 分析接口存在性能的根本原因
- - 业务接口存在for循环调用
  - 业务接口查db慢
  - 复合场景，存在较多查询
  - 接口勉强复合要求，但需要更高性能
后记

为什么要做接口性能优化

想象一下以下几个场景：

我们在获取一个用户详情接口时，刷了无数次，浏览器就在那转圈，硬是刷不出来，打开控制台，显示接口超时

假如我们服务A有个批量发营销短信的任务，服务A用批量的userid调服务B的用户服务以获取用户的手机号，从而完成短信发送功能。奈何服务B的通过userid接口获取用户详情的接口平均响应500ms以上，且接口请求量增大时，接口耗时明显上升，最后导致服务A的部分调用超时，短信发送失败

c端用户打开某些页面时，譬如用户空间或者用户详情页时，发现数据加载很慢，或者加载不出，导致用户体验大幅降低

etc…

以上只是列出了部分小的场景，在纷繁复杂的互联网业务领域，存在接口性能问题的场景更是不胜枚举。问题是有了，那么我们为什么要做接口性能的优化呢？

用户体验会得到显著提升
服务更稳定，性能更高，单位时间可处理的请求提升，响应指标有质的提升
有效防止了服务雪崩问题

怎样做接口性能优化，思路是怎样的

很显然，当我们讨论要做接口性能优化的时候，必然是此接口已经出现了一丢丢小毛病，确有优化的必要。譬如可能是用户感觉购物车有点卡，页面加载有点慢，又或者通过监控得知某些接口响应超出平均值太多…当有这些类似迹象发生时，我们就要开始着手处理，做性能优化了。从个人所经历的职业生涯来看，主要分为以下几个步骤：

确定是哪个接口存在性能问题
确定这个接口的内部逻辑是怎样的，做了哪些事情
分析接口存在性能问题的根本原因
寻找确立优化方案
回归验证方案效果

其中第1、2步相对比较容易处理，而核心在于第3、4步，第5步是用于验证效果。下面本文重点会探讨第3、4步如何进行处理

分析接口存在性能的根本原因

为什么说这个很重要呢，因为这个直接影响到后面选择何种优化方案，会消耗多少成本。当然，接口存在性能问题的具体案例千千万，笔者就从遇到过的着手，从最常见、最简单的开始说明

业务接口存在for循环调用

举例来看，这种场景就是A接口存在性能瓶颈，经分析发现，A接口实现里会同步for循环调用某个正常的接口B(or 方法、耗时处理逻辑)，以模拟代码来看，典型的如同下面这种：

//性能瓶颈处
List<T> list = xxx
for (T t: list) {//b.biz 接口(or方法、耗时处理逻辑)b.biz(t);
}

上述代码是我们在写业务代码是极有可能出现的，假定b.biz这块每次同步调用耗时均值为50ms，如果这个list.size()>10，那这个接口经过这个for循环后，耗时将达500ms以上，且size越大，耗时就越高。那么针对此种调用，如何进行优化呢？
针对这种case，优化有多种方案：

将b.biz处改成批处理，这是最佳实践。但这样处理也可能存在问题，譬如b.biz()接口本身不存在这个批处理接口，亦或者无法改成批处理
如果本身能确定list 的size不会很大，譬如超过10，成本最低，改造速度最快的方法就是使用java8中的集合的parallelStream()方法，该方法会并发地执行。缺点就是无法控制并发的粒度
在无法改造b.biz接口，且list.size()又比较大的情况下，可以使用自定义线程池，并发地调用。如果存在需要获取b.biz()返回值的场景，并发调用时可使用countDownLatch等待获取全部返回值。缺点就是b.biz()接口瞬时会承受比较大的压力，极端情况下服务可能被打垮，这种不作为推荐使用方案（b.biz()接口做了缓存且承受力较强的话可以考虑）

业务接口查db慢

这种场景还是很常见的，典型的如以下代码：

doSmt()
//典型的查db耗时高
List<T> list = xxxDao.selectXXX(xxx)
doSmtAnother()

很显然瓶颈在于查库慢，但是关于这种case，如果细究起来可能得另开一章sql优化来讲了。可以稍微提几点，当发现查db慢时，可以从以下几个方向着手：

确定是否为最后执行的sql慢
如果是执行的sql慢
- 查看该sql的执行计划，分析sql是否存在优化的可能。典型sql优化增加有效索引，优化搜索字段顺序，避免索引失效等情况。详情可参考： sql优化
- 如果已优化过，依然很慢，得分析是否是表数据量过大，譬如以前我们dba推荐mysql库单表行数量不要超过3kw，实践中也发现，当单表数据量过大时，单纯从sql优化的角度着手是无法解决性能问题的。此时可能得考虑分库分表，或采取其他的存储方式

复合场景，存在较多查询

还有一种典型场景就是某个接口实现很复杂，业务逻辑多，调用其他接口或者方法的地方非常多，且接口的上下游链路里存在多个重复查询的情况(如A接口在调B接口之前查了C，然后调B接口时又查了一遍C)

针对此类场景，可以从以下方法着手：

确定接口的上下游是否存在重复调用的情况，若存在，可通过改造降低查询次数
接口的实现是否过于复杂，分析是否存在有效简化的可能，针对耗时较高的部分定点优化，缓存、并发都可以采用

接口勉强复合要求，但需要更高性能

当我们到达山穷水尽的时候（缓存的银弹暂时不作讨论），倘若需要做更进一步的优化，可以着手的点有哪些呢？从个人浅薄的知识来看，我能想到的有如下这些：

如果是针对的前端静态资源类接口，可将资源前置，靠近相应的用户侧，采用cdn加速可有效改善资源类接口响应速度
如果是动态服务类接口，服务端的数据中心应选择恰当，另外对于Java语言后端服务来说，可以考虑从jvm性能调优的角度来进行优化，针对不同特性的应用，调整相应的gc算法及gc策略
如果针对的是超高并发、超高性能接口的场景，可考虑使用go语言开发此类核心接口

后记

当碰到更典型的case和更好的解决方案时，此篇文章会进行追加。欢迎有不同想法的小伙伴共同探讨