问题背景:
有如下a、b、c、d、e 5个服务,不同服务间调用关系如下 a->b->c->d、d->c->b->c->d、e->b->c->d 等场景,且均为同步调用。
其中调用方式为: a<=dubbo=>b b<=dubbo=>c c<=https=>d e<=dubbo=>b
此项目应用于交通行业,所以存在早晚高峰。
现象:某天下午18:00-19:00 运维告警d服务大量http连接c超时。d->c超时
思考1:c的网络问题|c服务内存满导致内部线程阻塞|
经确认:不是上诉问题。
经检查日志发现c->b 存在dubbo超时,b->c 也存在dubbo超时。
思考2: 因为abce等大量内部服务注册在同一个zk集群,同时这个集群还担任了分布式配置中心的角色。而且zk为了保证 高吞吐量和低延迟 将数据保存在内存中。
因为节点过多导致zk内存问题。
经确认:zk集群正常。(这个在后续新增服务时,考虑新增zk集群)
思考3: Dubbo超时机制:https://blog.csdn.net/sihai12345/article/details/80152224
经确认:服务之间的超时时间配置一致,符合业务场景要求
思考4: c->d的超时时间设置了60s,而在d->c->b->c->d链路中,c->b 超时时间为12s,b->c超时时间为20s。
经过日志核实:因为c->d超时,导致上游b->c超时,进而c->b超时,进而d->c。。
经以上梳理:得出结论,改变c->d的http超时时间< b->c的dubbo超时时间< c->b的dubbo超时时间
联系客服