为了减少接口的响应时间，有哪些优化措施？（可以从架构、代码等各个角度谈）？

为了减少接口的响应时间，有哪些优化措施？（可以从架构、代码等各个角度谈）？

 

 

我们在开发过程中，当然是希望自己项目接口的响应时间越短越好，至少我看着自己开发出来的代码，都是毫秒级的响应，会有一种自豪感；那么我们项目做了哪些优化，和大家分享分享。

 

优化代码

先从小处着手，代码写的好坏，直接影响到接口的响应速度；当然这里也不可能展开详谈每一行代码怎么写，主要还是说一下措施：

• 代码规范：我经常会以自己的标准去衡量其他开发人员代码的好坏，虽然我也不是什么大牛，但毕竟做了十多年的开发，所以很多时候组内年轻人的代码，在我眼里都是不合格的，为了短时间内提升他们的代码水平，只能制定详细的代码规范让他们去遵守；

• 项目级的处理方案：有些公共的功能，并不需要每个开发去写代码，比如异常处理，直接往上抛，会有统一的代码捕捉异常进行处理的。

• 集体Code Review还是有必要做的，一方面起到一个威慑的作用（大部分人都好面子，如果自己写的代码太烂被大家看到，也会不好意思，所以写代码的时候会小心一些），另外确实可以让开发人员取长补短。

 

缓存

缓存很重要，所以单独拿出来说。

• 出参入参直接缓存：某些场景下，是可以直接把入参作为key，出参作为value，直接缓存起来的，比如放到Redis中；我们有个项目是做费率计算的，需要根据入参查询费率表，并有大量的计算操作，这种场景有两个特点：一是费率信息不会改变，二是计算复杂费时，这个场景就非常适用于出参入参直接缓存（出参=计算结果）。

• 字典类型的数据，可以静态化后放入内存或第三方缓存中，并定时刷新缓存或做缓存失效的设置。

• 提前做数据的整合和加工：如果一个接口返回的数据需要几张表关联后才能提供，如果可以的话，尽量提前把这个关联做好；真正接口查询的时候，只查询关联后的结果就可以了。

• 总之，能查询缓存的话，尽量不要直接查询数据库。

 

接口拆分

设计和代码一样重要，甚至在我看来，设计比敲代码更重要；所以如何设计一个接口，是非常重要的（通常要全盘考虑）：

• 我见过这样的接口，号称万能接口，只对外提供一个接口，根据传入参数的不同，后面的业务逻辑也不相同，我是非常反感这样的做法。

• 垂直拆分：把一个庞大的接口，拆分成N个独立的小接口，每个接口可以独立部署、维护、迭代；但是接口的【大小】，是很考验开发人员（架构）的。

• 水平拆分：一方面把接口部署多套，前面挂负载均衡，这是水平拆分的一种；另外一种水平拆分，是将接口中的业务逻辑拆分后并行处理，也是可以减少接口的响应时间的。