保密原因,这里不透露系统名称
背景
存在A和B两个系统,A系统的核心实体entityA与B系统的核心实体entityB是 1 对多的关系,即:entityA : entityB ~ 1 : N
问题出现
- 服务A和B的请求数持续保持异常的高位
- 这两个服务的流量高于常规情况,且当时没有特殊业务活动会明显提升UV
- 数据库压力持续上升,并最终保持连接数和活跃连接数达到 100%
问题检查&解决
- 对于与数据库保持异常高连接数的微服务,执行熔断,暂时缓解数据库压力,稳定其他微服务正常运行
- 根据异常的微服务反查逻辑,发现循环依赖问题
- 随机提取了一个前述存在循环依赖问题的接口的日志跟踪id(trace id),发现该trace id下同时记录了对两个接口的多个不同时间点(毫秒差距)的请求日志,说明该请求确实在这两个接口间循环依赖
- 发布更新
- 恢复被熔断的服务
为什么直到数据库压力被打满才出现接口超时告警?
如果有循环依赖,应该测试阶段就已经发现接口请求失败?
这里原因有二
- web端接口超时配置是5min,rpc接口超时配置是1s
- a系统和b系统针对对应依赖接口的出错都有容错机制,会自动返回其他正常加载的信息