生产问题-feign调用连接超时问题记录

         由于之前部署的情况不是很清楚，在服务正式对外开放后，发现有一个服务在点击的过程中报feign连接超时的问题，但是又不是必现，只是偶尔超时。一时之间，我很兴奋，热血沸腾，拿出来我多年的修复经验，一一试过，从兴奋到疲惫再到放弃再到终于解决，排查过程虽然困难重重，但是最终也算略有收获，分享给遇到同样问题的小伙伴参考。

在此加粗一行字，任何疑难杂症都是由简单到极点的失误造成的。

           首先描述一下情况。  页面调用A 服务，A服务通过feign调用B服务，B服务查询数据库。等待15s，A服务报连接B服务超时，B服务无打印日志，不是每次都报超时，但是B服务只要打印日志的都是正常返回。

A服务配置概况，配置了feign超时时间，15s，报错的时候超时日志在A的日志里面。

B服务配置概况，跑了定时任务，配置了如下几行

hystrix:
  command:
    default:
      execution:
        isolation:
          strategy: SEMAPHORE，数据库使用的mysql，报错的请求在B服务没有日志。

排查开始：

1.刚开始以为只是平常的feign调用超时，以为配置了feign超时时间就可以，翻了配置文件，一看配置15s，后经过试验，配置15s的超时时间完全生效并且够用。

2.开始排查数据库问题，一个单条的sql文件，查询时间0.6ms，查看数据库连接数，5000，占用1000，没啥大问题，不是数据库查询超时报错。

3.问之前的同事，是否有其他的机器在跑这个服务，导致的负载，一个节点正确，一个节点错误，这种情况很像是会出现这种问题，最后确认只有这台机器有这个服务。之前公司配置的轮询，所以虽然怀疑，但是不能特别确切的说肯定有个服务存在。没有继续往下。

4.开始看服务日志，发现B服务没有日志，于是怀疑B服务SEMAPHORE 策略导致服务线程数满，对A服务执行拒绝策略，所以A服务连接不上，去掉配置，上线，发现问题依然存在，而且拒绝应该是直接返回失败，而不是等待15s报超时，这条路也不对。

5.开始看代码，发现进入controller之前有aop做统一处理，通过代理的方式调用controller，而且会获取执行任务和参数，通过日志打印，而B服务没有任何的日志打印，所以得出结论，A服务压根没有调到B服务。但是解决不了问题，请求到通过A转发，没调到B，就这么消失了，然后报了一个调用超时，这完全想不通。

        到此经过排查和试验，已经把所有能想到的和怀疑的东西都作了验证，依然无法找到feign调用偶尔超时的问题，这么玄学的问题，完全束手无策，一个请求到一半的请求突然消失的无影无踪，15s之后报了个超时，事了拂衣去，一点痕迹都没有，虽然过往的经验告诉我，这个问题最后肯定有个特别简单粗暴的错误，但是我确实没招了，也查不下去了。

        没法，找到领导，陈述了情况和调查结果，领导也没见过，然后去翻了翻机器看看，偶然发现还有一台机器，随后打开机器一看，发现上面还跑了一个节点，而且配置没有更新，数据库密码都是错的，负载到这个节点的请求，肯定查不到，所以造成了连接失败。

6.停掉服务，生产验证，问题解决。

总结：

         首先生产环境的问题排查，确实很不方便，尤其是这种问题，看不到注册中心，也没啥特别好的调试手段。只能通过日志分析加日常经验。服务部署不清晰这种情况，对一个线上的产品来说绝对是致命的，最起码在没问题的时候万事大吉，出了一点小问题，也让你捉摸不透其中的奥妙，然后折腾的你欲哭无泪，过程中看了feign，hystrix的源码，查看线上服务的线程情况，数据库的线程数等等，找了一圈，都没找到问题，再三确认确实没问题，只能再去向上反馈了。一台遗忘的机器引发的案件，历时一个星期，不过好歹最终解决了，happy。

留给遇到同样问题的小伙伴参考。有问题可以留言问我