优化API接口响应速度

前言

API接口响应慢？
SLA一直提不上去？
其实这是后端程序员想进阶必需要跨过去的坎：就是把它优化掉。
那么这其中到底有没有套路呢？答案是：有的。

本文将介绍目前正在用而且十分“无脑”有效的这个套路。

正文

埋点追踪分析，找出真凶

首先呢，第一部确定是在关键函数(有db、文件、复杂计算等操做)的先后，进行时间的记录。

此时去找log就能够找到每一步跑的时间。根据实际能够一眼看出是哪一步跑慢了。那么这一步就是主要优化的方向了。

ps:此类对线上接口产生的耗时基本能够忽略，因此放心用。

根据上下文，找到解决方案

既然找到了跑得慢的函数。那么就开始优化吧。

先说前提：前端已有lvs负载均衡、nginx反向代理转发请求。

首先须要分析为什么跑慢了？
1.是否是资源层面的瓶颈？
2.是否是缓存没添加，若是加了，是否是热点数据致使负载不均衡？
3.是否是有依赖于第三方接口？
4.是否是接口涉及业务太多，致使程序跑好久？
5.是否是sql层面的问题致使的等待时机加长，进而拖慢接口？
6.网络层面的缘由？带宽？DNS解析？
7.代码确实差？？？
8.未知？

暂时就想到这么多，有补充欢迎留言，谢谢。

对症下药
1.资源紧张，加机器，干上去，负载均衡搞起来
2.加缓存能够解决的问题都不是什么大问题，存在热点数据能够将某几个热点单独出来用专门的机器进行处理，不要由于局部影响总体
3.一方面与第三方沟通接口响应问题，另外一方面超时时间注意把控，若是能够非核心业务能异步久异步掉。
4.把非核心的业务进行异步化操做。记住若是代码层面是非核心业务，可是会影响用户感知，须要慎重决定是否异步。
5.若是是代码不良致使加锁了，尽可能优化索引或sql语句，让锁的级别最小（到行），通常来讲到行差很少了。若是是单个sql跑慢了，须要分析是否是索引没加或者sql选的索引错了，索引该加的就加了，该force index也加了。 6.网路缘由，须要联系运营商一块儿商量下怎么解决，单方面比较难有大的优化。 7.代码确实差，那也无药可救了。我选择狗带。