这篇文章将通过一个真实的线上事故,系统性地介绍:在微服务架构下,该如何正确理解并设置 RPC 接口的超时时间,让大家在开发服务端接口时有更全局的视野。
图片来自 Pexels
上面这张监控图,对于服务端的研发同学来说再熟悉不过了。在日常的系统维护中,“服务超时”应该属于监控报警最多的一类问题。
尤其在微服务架构下,一次请求可能要经过一条很长的链路,跨多个服务调用后才能返回结果。
当服务超时发生时,研发同学往往要抽丝剥茧般去分析自身系统的性能以及依赖服务的性能,这也是为什么服务超时相对于服务出错和服务调用量异常更难调查的原因。
本篇文章将分成以下四个部分:
从一次 RPC 接口超时引发的线上事故说起
事故发生在电商 APP 的首页推荐模块,某天中午突然收到用户反馈:APP 首页除了 banner 图和导航区域,下方的推荐模块变成空白页了(推荐模块占到首页 2/3 的空间,是根据用户兴趣由算法实时推荐的商品 list)。
上面的业务场景可以借助上图的调用链来理解:
粗看起来,两个依赖服务的降级策略都考虑进去了,理论上就算推荐服务或者商品排序服务全部挂掉,服务端都应该可以返回数据给 APP 端。
但是 APP 端的推荐模块确实出现空白了,降级策略可能并未生效,下面详细说下定位过程。
问题定位过程
第 1 步:APP 端通过抓包发现:HTTP 请求存在接口超时(超时时间设置的是 5 秒)。
第 2 步:业务网关通过日志发现:调用推荐服务的 RPC 接口出现了大面积超时(超时时间设置的是 3 秒)。
错误信息如下:
第 3 步:推荐服务通过日志发现:Dubbo 的线程池耗尽。
错误信息如下:
通过以上 3 步,基本就定位到了问题出现在推荐服务,后来进一步调查得出:是因为推荐服务依赖的 Redis 集群不可用导致了超时,进而导致线程池耗尽。
详细原因这里不作展开,跟本文要讨论的主题相关性不大。
降级策略未生效的原因分析
下面再接着分析下:当推荐服务调用失败时,为什么业务网关的降级策略没有生效呢?理论上来说,不应该降级去调用商品排序服务进行托底吗?
最终跟踪分析找到了根本原因:APP 端调用业务网关的超时时间是 5 秒,业务网关调用推荐服务的超时时间是 3 秒,同时还设置了 3 次超时重试。
这样当推荐服务调用失败进行第 2 次重试时,HTTP 请求就已经超时了,因此业务网关的所有降级策略都不会生效。
下面是更加直观的示意图:
解决方案
解决方案如下:
关于超时时间和重试次数的设置,需要考虑整个调用链中所有依赖服务的耗时、各个服务是否是核心服务等很多因素。这里先不作展开,后文会详细介绍具体方法。
超时的实现原理是什么?
只有了解了 RPC 框架的超时实现原理,才能更好地去设置它。不论是 Dubbo、Spring Cloud 或者大厂自研的微服务框架(比如京东的 JSF),超时的实现原理基本类似。
下面以 Dubbo 2.8.4 版本的源码为例来看下具体实现。熟悉 Dubbo 的同学都知道,可在两个地方配置超时时间:分别是 Provider(服务端,服务提供方)和 Consumer(消费端,服务调用方)。
服务端的超时配置是消费端的缺省配置,也就是说只要服务端设置了超时时间,则所有消费端都无需设置,可通过注册中心传递给消费端。
这样:一方面简化了配置,另一方面因为服务端更清楚自己的接口性能,所以交给服务端进行设置也算合理。
Dubbo 支持非常细粒度的超时设置,包括:方法级别、接口级别和全局。如果各个级别同时配置了,优先级为:消费端方法级>服务端方法级>消费端接口级>服务端接口级>消费端全局>服务端全局。
通过源码,我们先看下服务端的超时处理逻辑:
可以看到,服务端即使超时,也只是打印了一个 warn 日志。因此,服务端的超时设置并不会影响实际的调用过程,就算超时也会执行完整个处理逻辑。
再来看下消费端的超时处理逻辑:
FailoverCluster 是集群容错的缺省模式,当调用失败后会切换成调用其他服务器。
再看下 doInvoke 方法,当调用失败时,会先判断是否是业务异常,如果是则终止重试,否则会一直重试直到达到重试次数。
继续跟踪 Invoker 的 Invoke 方法,可以看到在请求发出后通过 Future 的 get 方法获取结果。
源码如下:
进入方法后开始计时,如果在设定的超时时间内没有获得返回结果,则抛出 TimeoutException。
因此,消费端的超时逻辑同时受到超时时间和超时次数两个参数的控制,像网络异常、响应超时等都会一直重试,直到达到重试次数。
设置超时时间是为了解决什么问题?
RPC 框架的超时重试机制到底是为了解决什么问题呢?从微服务架构这个宏观角度来说,它是为了确保服务链路的稳定性,提供了一种框架级的容错能力。
微观上如何理解呢?可以从下面几个具体 case 来看:
①Consumer 调用 Provider,如果不设置超时时间,则 Consumer 的响应时间肯定会大于 Provider 的响应时间。
当 Provider 性能变差时,Consumer 的性能也会受到影响,因为它必须无限期地等待 Provider 的返回。
假如整个调用链路经过了 A、B、C、D 多个服务,只要 D 的性能变差,就会自下而上影响到 A、B、C,最终造成整个链路超时甚至瘫痪,因此设置超时时间是非常有必要的。
②假设 Consumer 是核心的商品服务,Provider 是非核心的评论服务,当评价服务出现性能问题时,商品服务可以接受不返回评价信息,从而保证能继续对外提供服务。
这样情况下,就必须设置一个超时时间,当评价服务超过这个阈值时,商品服务不用继续等待。
③Provider 很有可能是因为某个瞬间的网络抖动或者机器高负载引起的超时,如果超时后直接放弃,某些场景会造成业务损失(比如库存接口超时会导致下单失败)。
因此,对于这种临时性的服务抖动,如果在超时后重试一下是可以挽救的,所以有必要通过重试机制来解决。
但是引入超时重试机制后,并非一切就完美了。它同样会带来副作用,这些是开发 RPC 接口必须要考虑,同时也是最容易忽视的问题:
①重复请求:有可能 Provider 执行完了,但是因为网络抖动 Consumer 认为超时了,这种情况下重试机制就会导致重复请求,从而带来脏数据问题,因此服务端必须考虑接口的幂等性。
②降低 Consumer 的负载能力:如果 Provider 并不是临时性的抖动,而是确实存在性能问题,这样重试多次也是没法成功的,反而会使得 Consumer 的平均响应时间变长。
比如正常情况下 Provider 的平均响应时间是 1s,Consumer 将超时时间设置成 1.5s,重试次数设置为 2 次。
这样单次请求将耗时 3s,Consumer 的整体负载就会被拉下来,如果 Consumer 是一个高 QPS 的服务,还有可能引起连锁反应造成雪崩。
③爆炸式的重试风暴:假如一条调用链路经过了 4 个服务,最底层的服务 D 出现超时,这样上游服务都将发起重试。
假设重试次数都设置的 3 次,那么 B 将面临正常情况下 3 倍的负载量,C 是 9 倍,D 是 27 倍,整个服务集群可能因此雪崩。
应该如何合理的设置超时时间?
理解了 RPC 框架的超时实现原理和可能引入的副作用后,可以按照下面的方法进行超时设置:
总结
最后,再简单总结下:RPC 接口的超时设置看似简单,实际上有很大学问。不仅涉及到很多技术层面的问题(比如接口幂等、服务降级和熔断、性能评估和优化),同时还需要从业务角度评估必要性。
知其然知其所以然,希望这些知识能让你在开发 RPC 接口时,有更全局的视野。
根据《市场与市场人工智能网络安全预测报告》,预计到2026年,人工智能网络安全...
相信很多人都有过被封号的经历,有的可能改密码就自动解封了,有的可能七天后就...
我预估在未来15年内,人工智能将会减少美国40%到50%的就业机会。 创新工场董事长...
作为智能手机的领军者,每一代iPhone都会采用***技术,让市场眼前一亮。然而,近...
自打进入2021年之后,微信的新版本几乎都是从iOS版开始。无论是最初的全屏动态表...
最近,南京、江苏、天津等地开始禁用AI人脸识别技术。 11月底,南京一男子带着头...
想学习机器学习吗?从这10本书开始。 Top 10 Books on Machine Learning For Abso...
中国自动驾驶迎来新突破,无人驾驶时代已来。9月15日,百度联手央视新闻全程直播...
在近日举行的2020中国5G+工业互联网大会上,中国信息通信研究院院长刘多指出,近...
欧洲竞争电信协会官网日前发表声明,谴责出于地缘政治对中国5G供应商实施的任何...