背景
项目中有一个提交接口，在后端逻辑中，需要先调用查询第三方接口列表AList的接口，根据返回结果循环中掉调用单条更新AUpdate的接口，之后再根据当前循环的数据，去查询第三方查询列表BList接口，再根据返回结果中，调用单条更新BUpdate接口
为啥不做成batch？因为第三方不支持batch更新，同时查询BList接口的查询条件，也不支持传入多个条件，所以只能在AList返回结果的循环中去查询
接口写好了之后，发现提交之后居然需要25s+的时间才能返回处理结果 what？这是啥效率？也太慢了吧
思路
思考之后，认为问题有二：
- AList返回结果的循环中去一个个调用AUpdate接口，假如AList size=10，则需要调用10次，一次1s，那也是10s了
- BList返回结果中，又一个个去调用BUpdate接口，那如果BList size=10，1次1s，那累计时间就是10 x 10 x 1 = 100s，那速度肯定慢呀
因为需求不接受异步查询执行结果，那既然一次次这么慢，就改为多线程吧，按照上例，累计时间充其量最多也就是 2s + 2s = 4s吧
按照这个思路改了代码之后测试，发现相应速度确实快了，但也还是处于不可接受的范围内，平均10s
这就头大了，咋办？测试让优化速度，说代码有问题，这不得拿点真凭实据出来看看证明一下？ 此时想到可以搞一下链路追踪，看下累计时间和每个调用花的时间，不就对了，于是想到之前项目中用到过的Skywalking
Skywalking安装
-
下载地址，版本随意，我这里选择的9.7.0
-
在对应的java springboot项目jvm参数中加入如下参数
ini
-javaagent:/your_skywalking_install_path/apache-skywalking-apm-bin/agent/skywalking-agent.jar
-Dskywalking.agent.service_name=your_server_name
-Dskywalking.collector.backend_service=127.0.0.1:11800- 启动你的java springboot服务
- 访问你自己服务的接口
- 访问http://localhost:8080/trace
- 在trace中，就可以看到你自己接口的调用以及耗时了
对应左侧，就是每个请求信息，右侧，则是对应链路耗时信息
结论
以我这个请求为例，开始以为是AList和BList返回的结果过多导致，可尝试两个返回结果都只1条为例，总计耗时依然到了6998ms，通过上图的链路追踪信息发现，耗时最多的操作基本都在http调用上，AUpdate耗时2999ms，BList耗时401ms，BUpdate耗时2879ms，这里就花了6280ms，而这两个操作，业务逻辑并不允许并行执行，必须要前者成功之后才能执行后者
这下报告甩到测试脸上，终于没话说了，只能产品自己去改需求了，要么就只有自己默默接受这么长的耗时