【美好，一直在身边】惊呆了，RPC超时设置竟然引发了线上事故！ |Redis|算法|文章

这篇文章将通过一个真实的线上事故，系统性地介绍：在微服务架构下，该如何正确理解并设置 RPC 接口的超时时间，让大家在开发服务端接口时有更全局的视野。

本文插图

图片来自 Pexels

本文插图

上面这张监控图，对于服务端的研发同学来说再熟悉不过了。在日常的系统维护中， “服务超时”应该属于监控报警最多的一类问题。
尤其在微服务架构下，一次请求可能要经过一条很长的链路，跨多个服务调用后才能返回结果。
当服务超时发生时，研发同学往往要抽丝剥茧般去分析自身系统的性能以及依赖服务的性能，这也是为什么服务超时相对于服务出错和服务调用量异常更难调查的原因。
本篇文章将分成以下四个部分：

从一次 RPC 接口超时引发的线上事故说起
超时的实现原理是什么?
设置超时时间到底是为了解决什么问题?
应该如何合理的设置超时时间?

从一次 RPC 接口超时引发的线上事故说起
事故发生在电商 APP 的首页推荐模块，某天中午突然收到用户反馈：APP 首页除了 banner 图和导航区域，下方的推荐模块变成空白页了(推荐模块占到首页 2/3 的空间，是根据用户兴趣由算法实时推荐的商品 list) 。

本文插图

上面的业务场景可以借助上图的调用链来理解：

APP 端发起一个 HTTP 请求到业务网关。
业务网关 RPC 调用推荐服务，获取推荐商品 list 。
如果第 2 步调用失败，则服务降级，改成 RPC 调用商品排序服务，获取热销商品 list 进行托底。
如果第 3 步调用失败，则再次降级，直接获取 Redis 缓存中的热销商品 list 。

粗看起来，两个依赖服务的降级策略都考虑进去了，理论上就算推荐服务或者商品排序服务全部挂掉，服务端都应该可以返回数据给 APP 端。
但是 APP 端的推荐模块确实出现空白了，降级策略可能并未生效，下面详细说下定位过程。
问题定位过程
第 1 步：APP 端通过抓包发现：HTTP 请求存在接口超时(超时时间设置的是 5 秒) 。
第 2 步：业务网关通过日志发现：调用推荐服务的 RPC 接口出现了大面积超时(超时时间设置的是 3 秒) 。
错误信息如下：

本文插图

第 3 步：推荐服务通过日志发现：Dubbo 的线程池耗尽。
错误信息如下：

本文插图

通过以上 3 步，基本就定位到了问题出现在推荐服务，后来进一步调查得出：是因为推荐服务依赖的 Redis 集群不可用导致了超时，进而导致线程池耗尽。
详细原因这里不作展开，跟本文要讨论的主题相关性不大。
降级策略未生效的原因分析
下面再接着分析下：当推荐服务调用失败时，为什么业务网关的降级策略没有生效呢?理论上来说，不应该降级去调用商品排序服务进行托底吗?
最终跟踪分析找到了根本原因：APP 端调用业务网关的超时时间是 5 秒，业务网关调用推荐服务的超时时间是 3 秒，同时还设置了 3 次超时重试。
这样当推荐服务调用失败进行第 2 次重试时， HTTP 请求就已经超时了，因此业务网关的所有降级策略都不会生效。