2019-05-23 优化接口记录

背景介绍

今天有客户a反馈明明提交了资质但是无法看到，于是主管打算让我查看并且修复一下，通过和接口开发的同学咨询发现了问题所在，是由于调用应用B接口造成的，具体原因是：客户a查看自己的资质需要通过工单号调用我们的查询接口A，我们再以自己的信息调用B的相关接口Aa，获取相关信息，这个时候需要注意的是：客户a的数据是我们数据A的一部分可以理解为子集，我们以自己的账号信息获取在应用B的数据，所以可以总结为： a ∈ A，A∈B。

优化过程

由于目前是通过分页来获取的B中的数据【sum=number size】，而目前页码是固定的，想到的第一个解决办法就是扩大没有大小。

优点：
  1. 可以快速解决目前问题。
缺点：
  1. 随着数据的增加，size需要相应的进行修改来匹配到新增的数据，这个时候就会涉及到硬编码，当然也可以通过配置文件来避免这个问题；
  2. 如果设置的size太大会导致，B获取数据库时间加长，从而导致超时发生；

这个时候如果有多个线程来异步调用B的接口获取数据，可以增加单位时间内获取的数据，这个时候即使size设置的不是很大也可以获取到可观的数据。

优点：
  1. 可在较短时间获取大量的数据解决了接口调用超时和客户增加数据导致size增大的问题；
缺点：
  1. 开发难度，日志查看较麻烦需要打好标记。
  2. 如果设置的线程较多，容易导致查询接口的流控发生；

设置定时器，定时从B中同步数据到A中，这样a就可以直接从A中获取自己数据。

优点：
  1. 可在较短时间获取大量的数据解决了接口调用超时和客户增加数据导致size增大的问题；
缺点：
  1. 开发难度 ，日志查看较麻烦需要打好标记；

总结

  在测试过程中发现调用超时问题，具体来说是：通过分析应用A接口的开始时间t1 结束时间t2 和应用B接口的开始时间T1和结束时间T2.来分析超时发生在何处，如果在T1和T2直接说明是应用B代码可进行优化，如果发生在t1和t2直接同理如上，通过分析发现是t1到T1之间通信造成的，这个时候需要验证问题定位的准确性，通过对比分析发现其他调用应用B的接口没有发生这种情况，所以排除掉该可能性，后来通过 tail -f 命令实时监控发现是T1到T2之间查询数据库造成的时间超时，这个时候想到线程异步调用暂时解决该问题，为以后彻底解决提供较充分的时间。