微服务循环依赖问题

本文探讨了一起因微服务循环依赖导致的数据库压力问题,详细分析了问题出现的原因、检查方法及临时和长期解决方案。通过调整接口超时配置、优化业务逻辑、实施异步处理和加强架构审查,以防止类似问题再次发生。
摘要由CSDN通过智能技术生成

保密原因,这里不透露系统名称

背景

存在A和B两个系统,A系统的核心实体entityA与B系统的核心实体entityB是 1 对多的关系,即:entityA : entityB ~ 1 : N

问题出现

  1. 服务A和B的请求数持续保持异常的高位
    • 这两个服务的流量高于常规情况,且当时没有特殊业务活动会明显提升UV
  2. 数据库压力持续上升,并最终保持连接数和活跃连接数达到 100%

问题检查&解决

  1. 对于与数据库保持异常高连接数的微服务,执行熔断,暂时缓解数据库压力,稳定其他微服务正常运行
  2. 根据异常的微服务反查逻辑,发现循环依赖问题
  3. 随机提取了一个前述存在循环依赖问题的接口的日志跟踪id(trace id),发现该trace id下同时记录了对两个接口的多个不同时间点(毫秒差距)的请求日志,说明该请求确实在这两个接口间循环依赖
  4. 发布更新
  5. 恢复被熔断的服务

为什么直到数据库压力被打满才出现接口超时告警?

如果有循环依赖,应该测试阶段就已经发现接口请求失败?
这里原因有二

  1. web端接口超时配置是5min,rpc接口超时配置是1s
  2. a系统和b系统针对对应依赖接口的出错都有容错机制,会自动返回其他正常加载的信息

长期解决方案

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值