如何将一个8s的接口优化到500ms以下

最近换了个工作，刚入职就接了个活--优化公司自营app的接口性能，提升用户体验。

刚开始还以为是1s优化到500ms这种，或者500ms优化到200ms的接口，感觉还挺有挑战的。下好app体验了一下。好家伙，那个慢已经超过了我的忍耐力，瞬间就不想用这个app了，挺佩服那些坚持使用该app的用户。

生产环境其实还好，因为服务器配置好，RT保持在3~4s左右，测试环境就不行了，8s起步。测试同学每次为了测一个下单的小功能，就要先进行搜索，详情，订单确认等接口，累计都快30s的前置操作。我更好奇测试同学这几年是怎么坚持下来的。

还要说下公司的项目，微信小程序起步，最开始是找了个外包团队，用了一套很古老的代码完成的，只能保证功能正常进行，但是代码性能就从没考虑过（想必接过外包活的朋友应该深有体会）。去年开始研发了app，重心逐步向app靠拢了。但是过慢的响应严重影响了公司的推广，于是就把这个活交给了我。

出于篇幅和隐私原因，本文不太会涉及具体业务代码和SQL，部分SQL也会换成通用的表来说明，只是会说一下整个优化的思路。

好了，闲话不多说，马上进入正题。

宏观优化

第一步：sql优化

在做性能优化的第一步，一定是先看有没有慢查，因为这个是不需要做任何分析就能拿到的结果。先找公司运维同事拉了一份慢查清单，真的是让我大开眼界。

10张表的关联查询，无处不在的or语句，like '%%'语句等等，甚至有些sql由于是mybatis-plus生成的sql语句，都找不到从哪调用的。没办法，一步一步来吧。

首先是表关联查询，10张表的sql我实在优化不动，看了下对应的接口QPS，不太高，最先放弃了，这个只能是等以后系统重构再考虑了。

or语句也改的简单粗暴，直接用union all改造，相同的sql结果，RT直降90%。改法如下：

--原sql 
select * from user_info where user_id ='' or user_name like '%%' ;

--新sql 
select * from user_info where user_id ='' union all select * from user_info where user_name like '%%' ;

原理说明：or语句会破坏索引，改为union all以后，每条sql都会走各自的索引（先忽略那个like语句不走索引的问题），这样会大幅提升sql性能

like语句确实在当前技术层面下无法解决，要么改es，要么改需求（明确前缀匹配，或者强制带一个命中索引的条件）。

还要说一个点，也是我们经常容易犯的问题，就是索引缺失。在最开始的需求时，只用user_id这个字段查询，所以对它加了索引，过了一两年以后，需求变更，现在要对user_name也要进行查询了，写代码的时候就会忘记给user_name增加索引。又或者在数据量很低的情况下，没有命中索引也不慢，察觉不到，过了一两年数据累积多了，没有索引的问题就显露了。这种情况很好发现也很好解决，拿着慢查sql执行一下explain，就能发现问题，增加索引即可。

当然有时加索引并不是100%能解决问题，有可能提交的索引会被DBA打回，这就需要结合业务进行判断了，具体不赘述。

最后呢，我再补充个索引失效的案例。

select * from user_info where user_id in (select user_id from order where create_time>='')

这条sql非常慢，explain显示user_info表没有走索引，但是user_id是有索引的。进一步探究发现，子查询的结果最多也就10条数据，当我拿着查到的10条数据改为如下sql时，又显示走了user_id索引，非常神奇

select * from user_info where user_id in (1，2，3，4，5，6，7，8，9，10)

查询了一些资料得知，当in语句明确数量时，sql解析器是可以走索引的（除非in的数量过大）；但是当in是子查询的时候，解析器在选择索引时，由于不太清楚in的数量，并且user_info表的数量也不算太多（大概100万左右吧），它会选择主键索引去关联，这样就导致了user_id索引失效。

知道原因了就很好改了，稍微改一下代码，改成exist语句或者把子查询改成两段分别查询的代码即可。

第二步：串行调用改为并行调用

以详情页为例，这个接口调用了接近20个服务(RPC或查DB）来组装详情页信息，每一个查询又都是线性执行的，假设平均一个接口在100毫秒左右，光这些接口调用就用了2s+的时间，详情页不慢才怪。

这里的改动目标就很明确了，梳理一下这20个服务的层级关系，然后改为并行调用。

把没有相互数据依赖的接口放在一个CompletableFuture中并行调用。
有相互依赖的，可以用thenAcceptAsync调用，也可以放在另一个CompletableFuture中并行调用。这个选择方式，我会在第六步中详细说明一下。

这一步没什么可细说的，按照标准的并行开发方式改造即可，做好并发编程的一些基本防护，比如用独立的线程池，做好线程超时，线程报错等措施。

宏观层面的改造基本就算完成了。为什么要说是“宏观”呢，因为这两步改造不仅在慢的问题发现上很容易，在改造完成后的体验上也有质的飞跃。我在做完这两步以后，生产RT降到了1s左右，测试RT降到了2s左右。

微观优化

宏观层面的改造，发现容易，改造快，见效明显。如果我们的代码都是按规范实现的，那基本上宏观的改造完成后，接口的优化也就差不多了。如果还要提高接口性能，就要进行非常细致的接口梳理、分析，在拿到整个接口流程后，才能制定更详细的优化方案，这一步我称之为微观优化。

第三步：重复调用

重复调用是一个常见问题，通常发生在一个经过多年，多人，多需求迭代后的接口中。一般来说，重复调用分为两种类型，三个场景：

同一个接口反复调用
1. 一个接口中反复调用。通常来说，比较大众化的接口，如用户信息，商品信息等，后来的开发者会有意识的去查看整个接口的前置步骤有没有调用过，有的话就直接复用出参了。但如果是一个非常小众的接口，仅在特定的场景下调用，开发者可能就不会很仔细的阅读前置代码，直接在自己的子方法中调用了，而实际上该接口很有可能会在上面某个子方法中被调用过了。
2. 上下游接口中反复调用。这个是微服务中经常遇到的，尤其是大众化接口，比如查商品信息，有可能整个链路中，80%的服务都会重新查询一次商品服务。这个的优化需要考虑的点非常多，由于不属于我们今天所讨论的范畴，所以本文就忽略该场景了。
同一个下游服务类似接口反复调用。比如当前查询了用户接口，获取用户基本信息；过一段时间，需要获取用户积分，你期望在原接口上增加积分出参，但用户系统的同事会说，那个接口调用量太大，不建议增加出参增大RT，推荐给你一个专门查积分的接口；又过了一段时间，类似的情况查询用户会员等级。。。这样不断的累积下，导致你的服务RT越来越高。

我在本次的梳理中，这两个类型都遇到了，并且公司项目并没有分团队，所有代码都可以改。针对类型1，在梳理完流程后，把重复调用的方法从子方法抽到主方法中，作为参数传递；针对类型2，针对当前业务，重新写一个新接口，一次性把用户基本信息，积分，等级等信息拿到。

如果下游服务（如上文所述用户）并不归属你部分所管辖，也可以说服对应的同事帮你提供一个新的接口，比如我在前司就写过很多getxxxForOrder，getxxxForProduct等专用接口，因为这类合并查询的接口，可以显著降低下游服务的QPS，他们也会有动力去优化的。

第四步：循环中查db/远程服务

这是编程中的一个大忌，如果下游不愿意提供批量接口，或者是异步操作，又或者循环数量在可预见的未来，也不会超过2~3个，这么搞是可以的。但如果数量很大的情况下，这么写代码就不推荐了。

我在改造中遇到的非常夸张的点，是查询一个列表页接口，先根据主表分页查询到数据后，循环获取页面上需要的其他数据，比如订单表可能只有订单号，商品id，用户id等，拿到以后，循环调用商品接口，用户接口获取对应的商品名称、用户信息等。

这里的改造就是先拿到当前页需要展示商品id和用户id，调用批量接口拿到所有的商品信息和用户信息，再将这些数据转成map(重点)，在循环中用map.get(userId)或者map.getOrDefault(userId,"xxx")的方式拿到对应数据。

//注意，最后的(v1,v2)->v1一定要加上，即使你确定不会出现重复数据，养成这个习惯还是非常好的 
Map<Long, String> map = productList.stream().collect(Collectors.toMap(
o -> o.getProductId(), ProductInfo::getProductName,(v1,v2)->v1));

查db的也类似，不过有一点会让很多人困惑，感觉只能循环中查询，即：一对多或者多对多的表中，每次的查询条件都不一样。其实这种情况下，只需要将所有的数据全部in查询即可，然后转map的时候，将key进行拼接。

如下所述：

--比如一个活动(a)对应多个商品(p)，一个商品也可能对应多个活动 
--a1->p1,p2;a2->p3,p4; 
--p1->a1,a3,p2->a1,a4; 
--通常情况，循环中挨个查询的sql为:
select * from activity_product_rel where product_id='p1' and activity_id in('a1','a3'); select * from activity_product_rel where product_id='p2' and activity_id in('a1','a4'); 
--不妨改为如下SQL 
select * from activity_product_rel where product_id in('p1','p2','p3') and activity_id in('a1','a2','a3','a4');


Map<String, Object> map = activityProductList.stream().collect(Collectors.toMap
(o -> o.getActivityId() +"_"+ o.getProduct() , Function.identity(),(v1,v2)->v1)); 
//或者是下面的方式，根据实际情况选择 
Map<String, List<Object>> map =activityProductList.stream().collect(
Collectors.groupingBy(o -> o.getActivityId() +"_"+ o.getProduct() )); 
//循环中用如下方式获取数据 
map.get(activityId+"_"+productId)

要说的一点是，sql的提前查询也要考虑实际情况，不能滥用，如果真IN出来成百上千的数据，那还不如循环查询呢，总之，要结合db性能，索引命中情况后再做决定。

第五步：拆分in语句

这一步既是上一步的补充，也可以看成是独立的一点。

在正常的sql查询中，也会出现in语句中存在上千甚至上万的数据，严重影响了db性能，甚至出现不走索引的情况，这时就需要拆分in语句了，把一条sql拆成10条，并行执行，然后聚合查询结果。

自己简单实现了下面这个方法。

public static <T> List<T> splitIn(BaseMapper<T> mapper, QueryWrapper<T> wrapper, List<Object> inData, String column, ThreadPoolExecutor pool, int size) {
    if (inData.size() <= size*1.1) {
        QueryWrapper<T> newWrapper = wrapper.clone();
        newWrapper.in(column, inData);
        return mapper.selectList(newWrapper);
    }
    List<List<Object>> partition =ThreadPoolUtils.balancedPartition(inData,size);
    Function<List<Object>, List<T>> function = data -> {
        QueryWrapper<T> newWrapper = wrapper.clone();
        newWrapper.in(column, data);
        return mapper.selectList(newWrapper);
    };
    return AsyncUtil.supplyAsync(partition, function, pool).stream().collect(ArrayList::new, List::addAll, List::addAll);
}

public static <P, R> List<R> supplyAsync(List<P> paramList, Function<P, R> apply, ThreadPoolExecutor executor) {
    if (CollectionUtils.isEmpty(paramList)) {
        return new ArrayList<>(0);
    }
    List<R> result = new ArrayList<>();
    List<CompletableFuture<R>> futures = new ArrayList<>();
    for (P p : paramList) {
        CompletableFuture<R> future = CompletableFuture.supplyAsync(
                () -> apply.apply(p), executor);
        futures.add(future);
    }
    for (CompletableFuture<R> future : futures) {
        R r = future.join();
        result.add(r);
    }
    return result;
}

public static <T> List<List<T>> balancedPartition(List<T> list, int partitionCount) {
    int size = list.size();
    int baseSize = size / partitionCount;
    int remainder = size % partitionCount;

    List<List<T>> result = Lists.newArrayList();
    int start = 0;
    for (int i = 0; i < partitionCount; i++) {
        int end = start + baseSize + (i < remainder ? 1 : 0);
        result.add(list.subList(start, Math.min(end, size)));
        start = end;
    }
    return result;
}

主要说明三点：

inData.size() <= size*1.1这个判断主要是基于一些实际情况，比如size是1000，如果是1001的时候，明明和1000没啥区别，却被迫分组，这种情况下多线程反而比单线程要慢，所以增加了一定的冗余。这个可以根据实际情况做调整。
balancedPartition这个方法是让deepseek写的，自己也懒得动脑筋想算法了。原本用的是Lists.partition()做分组，但它的实际效果是，1001个数据按照size=1000分组，会变成一组1000个，一组1个，极度不平均，也会影响异步的总RT，于是就想找个平均拆分的算法。
线程池和数量都作为入参传入，所以让不同的场景各自定义不同的数据，甚至可以通过配置中心来实时调整。

第六步：CompletableFuture线程分组

调试过程中，我把第二步优化的每一个方法的RT都打印，把异步的总时间也都打印，发现最慢的一个接口500ms左右，但是异步总时长却在1s左右。

在理想情况下，异步的总时长应该只会比最慢的接口再慢二三十毫秒，现在既然慢了快一倍，那就说明存在线程等待问题。

而解决线程等待的问题上，不是一味的加大线程池数量就可以的，这样治标不治本的，反而会加重CPU的负担。在仔细查看了所有接口的RT后，我决定做线程池分组。

目前分成了heavy和lite两个组，把那种大于300ms的服务放入heavy中，其他的放入lite中。这样可以极大实现线程的复用，这么做了一个简单的分组后，就实现了理想的效果：最慢接口500+ms，异步总时长在550ms左右。

基于此，我们再聊下上面留得一个点，有接口依赖的异步，是用thenAcceptAsync还是放在另一个CompletableFuture中并行调用。

我的理解是，根据实际情况做分析，简单说下我的想法：

如果上游接口耗时较短，那么下游接口可以放在thenAcceptAsync调用，毕竟即使这样做了，总时长可能都超不过最慢的接口
如果有非常多的接口依赖同一个接口，那不如将它们和其他接口一并放到第二个CompletableFuture中执行。

其实说白了，就是尽最大可能压榨CPU性能，降低RT，哪个方式快用哪个。

最后要说一个必须注意的点，如果没有必要，不要在异步中使用异步，如果一定要使用，那线程池一定要分开，不然会出现主子线程死锁情况。

第七步：并行计算

上面的很多异步情况，其实都是指的IO密集型，如果是CPU密集型的情况下，我们通常是不太会考虑用并行的。但在本次优化中，我发现了这么一个点。

有一个计算金额的方法，速度很快，1~3ms内就能结束，所以for循环去处理也没啥大问题，但调用这个方法的总时长超过了300ms，仔细分析后发现，这里有200多个数据需要计算，虽然每一个都很快，但累积下来也是一个不小的数字了，我将foreach改为list.parallelStream().forEach后，RT骤降到30ms左右。

但还没有结束，list.parallelStream().forEach仅建议用来验证并行能否提高性能，并不建议实际开发中使用，因为它的底层使用的时候ForkJoin框架来拆分任务的，在某些情况下可能会导致主线程阻塞。我在前司就被这个点坑过，为两年前的代码买单。。。

所以如果想要使用并行计算，一定要自定义线程池，不要想着去赌不出问题的概率。

第八步：不要滥用redis

说起来，这个外包项目代码是极度迷信redis，几乎所有的地方都用到了redis，导致大key非常多，调用一次redis的时间比查mysql要慢多了，并且还很容易引发YGC甚至FULLGC。

所以我也对项目中redis的使用进行了一定程度的降温。具体体现在如下几点：

针对分页数据，redis可以存全量数据，但仅存核心数据，其余数据都需要通过查表来补充。其实这一步应该用es甚至纯查表来实现，奈何改动量太大，公司还没有es环境，退而求其次了。
for循环调用redis的地方，有些都改成了查一次db。这也是经过性能比对后的结果，主要还是redis每次查的数据量太大了。

写到这里，基本上通用的优化方案就说完了。这么一通改造下来，测试环境的RT已经完美的降到1s左右了，想想当初的8s，简直不敢想象。

个性化点

或者说“非通用性优化”。这些优化点可能只适用于我司，因为大部分改动都属于历史代码堆叠导致，改动上没什么借鉴意义，不过可以参考下梳理过程。

第九步：接口拆分

这也算是一个通病，就是如果一个底层服务的部分出参，能满足一个新接口的全部功能，那就直接复用，省时省力。但很多时候，这个底层服务有可能是给一个聚合服务提供的，内部有大量对于新接口无用的功能。

就比如一个查询商品图片的接口，入参productId，出参imgList，controller直接调用了商品详情页接口，把什么商品说明，优惠券，价格详情全查了一遍，但最后只用了其中的imgList。。。

这种改造也很简单，重写一个新的service方法，只调用查商品的下游接口就好（因为懒得针对这种情况专门再写一个只查图片的接口了），结果就是这个查图片的接口RT从500+ms直降到50ms以下

第十步：跳过验签

这是最有意思的一个点，验证了好久才找到原因。

起因是通过日志发现接口仅用了800ms，但是app端的响应就是要1.5s以上。刚开始以为是出参过大（50kb以上）导致下载慢，但是抓包发现它的Waiting(TTFB)就是用时1.3s，下载20多ms。然后还专门去查了TTFB怎么回事，怎么优化之类的，就不表述了。

后来无意中发现，直接调用对应服务器的接口，即：http://192.168.1.101:8080/getXXX，就是800多ms，但是如果通过完整的url调用，即http://test.domain.com/xxxx/xxxx/getXXX这种方式，就是1.5s左右。

然后就跟到了网关代码中，发现原来是鉴权服务非常慢。。。

但是列表页，详情页这些接口，本身就支持非登录状态下查询的，没必要进行鉴权。和产品沟通认可后，对着网关一通改造，做好配置，让详情页接口跳过鉴权，接口瞬间降到1s以下，涉及出参少的详情，甚至200ms就返回了。

//网上找的查看curl执行时长的方法
//使用方法就是，如果原本的curl是curl "http://127.0.0.1",那么就在curl后面先加上下面的内容，再写"http://"
curl  -w "Time to Connect: %{time_connect}\nTime to Start Transfer: %{time_starttransfer}\nTotal Time: %{time_total}\n" "http://127.0.0.1:8080/xxxx"

//如果不想要看到出参，就用下面这个方法
curl -o /dev/null -w "Time to Connect: %{time_connect}\nTime to Start Transfer: %{time_starttransfer}\nTotal Time: %{time_total}\n" "http://127.0.0.1:8080/xxxx"

第十一步：跳过业务逻辑

就是某些业务逻辑其实是由于业务框架限制导致（原始代码是一套很老的系统），很多代码在公司现业务逻辑中已经没意义了，就用更直接的方式替代。有如下几个点：

某个RPC耗时200ms，但十多个出参中，仅用了其中一个值，且该值是一个数据库配置，我就直接改成配置中心配置了。（说明，我是经过确认，该数据库配置已经无意义了，理论上就是一个常量，为了一些考量才用配置中心代替）
某个查询会依据上一个查询的结果中某个字段判断，为0的时候才会查，分析后发现，数据库里就没有非0的数据，于是把把前置查询逻辑移除。（说明，经过确认，原始代码是一套sass系统，而现业务非sass，就是固定一套逻辑，这样才删除的前置查询）
由于app是后起之秀，很多小程序业务逻辑其实并没有包含，但是底层却是相同的代码。我根据app的出参进行对照后，重写了个app专用接口，删减了大量逻辑，直接让app接口快到飞起，降到100ms左右。（说明，这里就有点定制化的意思了，其实是和业务开发有一些背道而驰，万一以后来个需求，得两个接口一起改了。不过也是咨询过业务和产品，确定app未来的发展方向后，才这么干的）