开始怀疑是网络问题,但没有证据.随后网关的一台机器突然宕机,这个现象引起了我们注意.在上次迭代中,我们服务有一次重大升级,所有请求均会经过网关服务转发,以实现Server/DB单元化绑定,问题可能出在转发环节...二 调查过程
网关本身无太多业务逻辑,依赖项非常少,为了实现时间最小损耗,技术框架采用spring cloud gateway,底层WebFlux 则使用了高性能的 Reactor 模式.在上线前的多次压测中...,网关服务表现非常优秀,时间损耗基本在毫秒级别.万万没想到上线没几天就挖了个大坑,必须要刨根问底调查清楚
2.1 第一次定位
由于刚迁移到新机房,可用于问题还原的监控手段不多,刚开始只能从查看pod云监控以及日志着手...,具体资料可以在网上搜,这里主要介绍定位过程....再一次分析内存中保留的对象内容
可以看出1000W+的对象中,全部记录的是我们每次请求的RouteUri Method 耗时等信息,通过关键字定位,这些对象生产的源头是GateWay的 GatewayMetricsFilter