一次服务端大面积接口响应时间骤增问题排查

目录

      一、事故背景

      二、线上排查

      三、问题确认

      四、总结

---

一、事故背景

昨天下午16:05，突然接到接口报警，服务端接口响应时间陡增。

接到报警后，我们查看我们自己的监控信息，确实如此。

于是，先放下手上其他事情，开始了排查之旅。

二、线上排查

首先猜想会不会是相关接口流量陡增或者代码逻辑比较复杂，处理比较响应慢。

于是首先看了流量情况和代码逻辑，发现代码逻辑很简单，主要都是对于下游接口的调用，而流量情况也比较平稳。

在这里没有发现异常点，排除了接口在我们服务内部处理耗时高的想法，于是，接下来我就看看耗时高的那些接口是不是报错了，果然，通过监控看到，耗时高的那些接口调用下游接口返回的状态码都是404

一时间有点迷糊，调用下游接口状态码是404响应难道不应该也很快吗？怎么会造成服务大面积耗时高呢？会不会是因为网络链路中其他的问题呢？通过监控排查发现其他链路中并没有异常点，于是也打消了其他链路问题这个猜想。

这个时候还是着眼于我们自己的服务监控情况。

看了这些接口的请求情况和响应情况，发现有的接口调用其他部门接口调用了几次，而且每次都是404了。

    这个时候回想起代码逻辑，才猛然意识到，我们调用使用的spring的resttemplate加了重试机制，但是这个时候还是有个疑问，如果第一次调用404了，然后不就是会立刻发起第二次调用吗，这个耗时应该也不会太高啊，最多也就不到10ms吧，其实，这还只是自己的猜想，有时候，自己想当然的事情事实上有可能并不会是那么回事，于是，还是看了下spring的resttemplate的重试机制，最后发现，他的重试机制是有间隔的，而且间隔时间默认是1s，至此，也就明白了，这些接口耗时高原来都是进行io阻塞了。

事实上，这只是其中一个问题点，而且，并不是主要的问题点。

在排查的过程中，发现这个接口的调用次数还不是太多，即使发生了404重试，下意识地觉得也不会造成大面积服务端接口耗时陡增呀。

于是，继续刨根问底，继续通过监控期望能找到其他的异常点，不出所料，通过监控发现，还有一个接口错误请求量是这个接口的将近2倍，而且都是发生了很多的timeout。

查看这个接口超时时间默认是1.5s，也就是说1.5s的时间都在io阻塞等待下游接口响应。

三、问题确认

至此，第一个接口404后默认1s间隔重试和第二个接口默认1.5s超时两个问题点算是找到了，这些接口流量还不算低，当有比较高的流量的时候，这个io阻塞几乎都把tomcat的线程池资源耗尽了，tomcat线程绝大部分时间都没有在做业务处理，即使tomcat已经创建了最大线程数，

这个时候就算是某些请求调用下游接口是正常的，能够很快拿到正确结果，但是，如果没有拿到CPU调度，也会很慢的。

四、总结

• 1. 有时候即使沟通其他部门，查看他们的接口耗时情况，即使他们的接口耗时正常，但是，也并不一定就表示是我们的问题，有可能问题出在网络链路中(nginx等)。
• 2. http调用重试机制还是要根据具体的业务场景进行使用，不能盲用。
• 3. 接口耗时超时时间要度量好，不宜过大不宜过短。
• 4. 问题排查要仔细而全面，不能放过任何蛛丝马迹，在没有确定证据之前不能想当然判定哪里有问题或者决定一个想法，一旦确定问题，处理要果断。

以上是个人的亲身经历及总结经验，个人之见，难免考虑不全，如果大家有更好的建议欢迎大家私信留言。

如果觉得对你有一点点帮助，希望能够动动小手，你的点赞是对我最大的鼓励支持。

更多分享请移步至个人公众号，谢谢支持😜😜......

公众号：wenyixicodedog