微服务循环依赖调用引发的血案

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 微服务循环依赖调用引发的血案


问题表现

最近的迭代转测后遇到了一个比较有意思的问题。在测试环境整体运行还算平稳,但是过一段时间之后,就开始有接口超时了,日志中出现非常多的 “java.net.SocketTimeoutException: Read timed out”。试了几次重启大法,每次都是只能坚持一会之后,再次出现 SocketTimeoutException。

注意 :在测试环境于遇到问题重启服务,并不是一个好的实践,因为重启可能会让不容易出现的问题现场被破坏。如果问题在测试环境不能再重新,却在发版后出现在生产环境的话,那不仅会造成生产运维事件,还要在巨大的压力下去解决问题。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

初步分析

顺着测试汇报的出现问题的场景,跟踪调用链上相关服务的日志,发现出现了微服务之间循依赖调用。大致情况可以抽象如下所示(图中所有调用都是 http 协议):

  • Client 调用服务 Foo.hello()
  • Foo.hello() 逻辑中会调用服务 Boo.boo()
  • Boo.boo() 又调用回服务 Foo 的另外一个方法 another()

当然真实的场景要比较这个复杂,调用链更长,不过最终形成了环形依赖调用。至于这个环形依赖为什么回导致超时,当时想了多种可能,比如数据库慢查询、数据库锁、分布式锁等等。但是整个调用链上都是查询请求,而且查询相关的数据量也非常小,不会有锁存在。发生问题的时候也没有与查询数据相关的数据库写请求。

鉴于这个环形依赖调用确实是这个迭代版本中引入的变更,以及虽然没有理清其中的因果关系原理,但是这个环性依赖调用还是很可疑的,而且是不必要的环形调用。就抱着将环形依赖调用去掉试试看的态度,做了修复。修复完后,SocketTimeoutException 不再出现了。问题解决了。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

探寻原因

问题虽然不再出现,但是凭运气解决的问题,通常有可能不是真的的解决。只有弄清楚背后的原理,我们才能真正的确认问题是不是这个原因导致的,这样的修复是不是真的把问题解决了。

通过假设环形调用就是导致调用超时的直接原因。我们看看能不能推出因果关系。通过把Foo 服务容器画的更详细一点,如下图:

通过这个图示,我们可以发现,如果容器中接收请求的线程池如果都在等待服务Boo.boo() 的响应,而 Boo 又需要调用回服务 Foo.another()。这个时候,如果所有的线程都处于这样的状态,我们就会发现服务 Foo 容器中以及没有线程来处理 Boo 的请求了。某种程度上来说就是死锁了。到这里,我们就可以很确定了,这个环形依赖调用就是导致出现调用超时的罪魁祸首。当 client 发起的请求速度大于这个环形调用链的处理速度的时候,慢慢的就会导致服务 Foo 的所有线程都进入这种死锁状态。

验证

这里只列出关键的代码,具体的代码可以参考 gitee 工程:https://gitee.com/donghbcn/CircularDependency

Eureka 服务器

建个简单工程将Eureka server启动起来。

服务 Foo

创建 SpringBoot 工程实现 Foo 服务。Foo 通过 FeignClient 调用 Boo 服务。设置缺省的容器 Tomcat 的最大线程数为 16,Tomcat 默认配置最大线程数 200,对于验证这个场景有点了大了,要看到效果需要等的时间有点长。

application.properties

spring.application.name=demo-foo
server.port=8000
eureka.client.serviceUrl.defaultZone=http://localhost:8080/eureka
server.tomcat.threads.max=16
package com.cd.demofoo;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class FooController {
    @Autowired
    BooFeignClient booFeignClient;
    @RequestMapping("/hello")
    public String hello(){
        long start = System.currentTimeMillis();
        System.out.println("[" + Thread.currentThread() +
                "] foo:hello called, call boo:boo now");
        booFeignClient.boo();
        System.out.println("[" + Thread.currentThread() +
                "] foo:hello called, call boo:boo, total cost:" +
                (System.currentTimeMillis() - start));
        return "hello world";
    }
    @RequestMapping("/another")
    public String another(){
        long start = System.currentTimeMillis();
        try {
            //通过 slepp 模拟一个耗时调用
            Thread.sleep(100);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("foo:another called, total cost:" + (System.currentTimeMillis() - start));
        return "another";
    }
}

服务 Boo

创建 SpringBoot 工程实现 Boo 服务。Boo 通过 FeignClient 调用 Foo 服务。

package com.cd.demoboo;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class BooController {
    @Autowired
    FooFeignClient fooFeignClient;
    @RequestMapping("/boo")
    public String boo(){
        long start = System.currentTimeMillis();
        fooFeignClient.another();
        System.out.println("boo:boo called, call foo:another, total cost:" +
                        (System.currentTimeMillis() - start));
        return "boo";
    }
}

Jmeter

采用 Jmeter 来模拟并发 Client 调用。配置了30 个 线程,无限循环。

很快服务 Foo 日志就卡死了。过一会 Boo 的日志开始出现 SocketTimeoutException,如下图:

jstack

通过 jstack 我们可以看到 Foo 进程的所有线程都卡在 hello() 调用上了。

总结

微服务之间的环形依赖类似于类之间的循环依赖,当依赖关系形成了环,会造成比较严重的问题:

  • 微服务直接不能形成环形调用,否则非常容易出现死锁状态
  • 微服务之间的耦合性非常强,这严重违反了微服务的初衷;这种情况往往是服务之间的调用没有约束导致的,为了方便取到或更新数据,服务之间可以随意的调用,以”微服务“为设计目标的系统会逐渐演变成一个分布式大单体


相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
7月前
|
消息中间件 存储 安全
微服务之间的数据依赖问题是怎样的?
微服务之间的数据依赖问题是怎样的?
155 0
微服务之间的数据依赖问题是怎样的?
|
8月前
|
供应链 架构师 数据库
架构师带你搞明白微服务进阶场景实战:服务之间的数据依赖问题
数据同步 上面讲解了数据一致性的解决方案,这一篇来讲讲服务之间的数据依赖问题,还是先来说说具体的业务场景。 业务场景:如何解决微服务之间的数据依赖问题 在某个供应链系统中,存在商品、订单、采购这3个服务,它们的主数据部分结构表如下。
架构师带你搞明白微服务进阶场景实战:服务之间的数据依赖问题
|
10月前
|
安全 网络协议 Java
IDEA 集成 Docker 插件实现一键远程部署 SpringBoot 应用,无需三方依赖,开源微服务全栈有来商城线上部署方式
IDEA 集成 Docker 插件实现一键远程部署 SpringBoot 应用,无需三方依赖,开源微服务全栈有来商城线上部署方式
|
10月前
|
canal 供应链 负载均衡
电商系列:本文以商品订单为例来讲述微服务之间的依赖如何处理?
电商系列:本文以商品订单为例来讲述微服务之间的依赖如何处理?
138 0
|
新零售 移动开发 监控
微服务进阶场景实战:BFF,如何缓解服务依赖复杂度的问题?
前面处理了服务间数据依赖的场景。 除了这种频繁需要其他服务的数据的场景,其实还会碰到服务间依赖太杂乱的问题。 本篇讨论的就是如何缓解服务依赖复杂度的问题。 先把整个业务场景描述一下。
|
Java Maven 微服务
微服务项目中maven依赖引入失败爆红问题解决方案
微服务中maven中标签dependencyManagement依赖引入失败的原因解决方案
543 0
微服务项目中maven依赖引入失败爆红问题解决方案
|
Prometheus 监控 前端开发
SpringCloud升级之路2020.0.x版-6.微服务特性相关的依赖说明
SpringCloud升级之路2020.0.x版-6.微服务特性相关的依赖说明
SpringCloud升级之路2020.0.x版-6.微服务特性相关的依赖说明
|
监控 Java Docker
Spring Cloud构建微服务架构:服务容错保护(Hystrix依赖隔离)【Dalston版】
Spring Cloud构建微服务架构:服务容错保护(Hystrix依赖隔离)【Dalston版】
90 0
Spring Cloud构建微服务架构:服务容错保护(Hystrix依赖隔离)【Dalston版】
|
监控 Java API
使用Hystrix实现自动降级与依赖隔离[微服务]
这篇文章是记录了自己的一次集成Hystrix的经验,原本写在公司内部wiki里,所以里面有一些内容为了避免重复,直接引用了其他同事的wiki,而发布到外网,这部分就不能直接引用了,因此可能不会太完整,后续会补充进去。
958 0