记一次线上问题之：dubbo接口超时Invoke remote method timeout

问题背景：

　　有如下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超时时间