前言
现在,大多数的互联网公司都是基于微服务来开发和部署相关的项目.这就免不了服务与服务之间的相互调用,最简单的形式是HTTP,当然也可以是RPC.如Thrift,Dubbo等等.这种服务的调用方,也就是客户端在调用过程中,都会有一个调用的超时时间配置.那这个时间要配置多少才算合理,就是这篇文章要讨论的问题.
场景
服务一依赖于两个服务的数据,然后完成此次操作.那就是两次对其他服务的调用,当依赖服务都运行正常的时候,什么问题都没有.但是,一旦发生意外,依赖服务二在你不知情的情况下,响应时间变长,甚至停止服务,而你的客户端超时时间设置过长,则你完成此次请求的响应时间就会变长.Java的Servlet容器,无论是tomcat还是jetty都是多线程模型.都用worker线程来处理请求.一般都可以配置.当你的请求打满worker线程的最大值之后,剩余请求会被放到等待队列.但是等待队列也有个大小,一旦等待队列都满了,那这台webserver就会拒绝服务,对应到Nginx上返回就是502.如果你的服务是QPS较高的服务,那基本上这种场景下,你的服务也会跟着被拖垮.如果你的上游也没有合理的设置超时时间,那故障会继续向上扩散.这种故障逐级放大的过程,就是服务雪崩效应.如下图
配置依据
一般来说,超时时间可以设置为调用服务的TP99.9的时间.当然也需要根据业务场景进行分析和设置.
总结
一个小小的配置,就足以引发重大故障.当然也不是说配置了超时时间,这个问题就完全得到解决.关键服务的监控报警.非必要服务的自动降级.都是应该去梳理,关注的点.上线的服务,没有一个是简单的.存在即合理.
