服务是正常的，有个service有的时候能依赖，有的时候没有找到依赖(no named bean 'XXXXservice' defined)

 1、 排查思路一: 服务是正常的，偶尔找不到依赖，怀疑是部署的问题，通知运维重新部署，问题依然存在；
 2、 排查思路二: 查看代码重新验证，本地再次验证，测试环境再次验证一切正常的，怀疑是生产代码没有部署上去，
 但是服务偶尔是正常的，两个思路有点互斥，但是是排查问题，只能看生产的部署代码，拉生产代码反编译文件，发现代码确实是最新的,
 问题依然存在，继续排查;
 3、 排查思路三: 生产项目部署环境，单台服务器，两个tomcat,nginx做的负载均衡; 由上面排查思路一可猜想到是否是某个tomcat的代码没有更新的，
 找运维确认，用的多实例部署，这里多实例指的就是两个tomcat用的一个路径的代码，运维确认没问题，不然服务会一直报错的；
 4、 排查思路四: 坚持自己的想法，按照自己的思维排查，不受其它人的干涉，其它的人提供的信息只是用于问题定位;继续排查，
 找运维切换tomcat，tomcat逐个测试，最后发现一个tomcat是正常的，和测试环境一样的，
 另外一个tomcat一直报依赖没有定义(no named bean 'XXXXservice' defined)，如此这样问题已经定位:负载均衡的一个tomcat的代码还是老代码；
 5、问题解决:  经过以上，问题已经定位，接下来就是问题解决了。思路:既然两个tomcat用的一个代码路径，为什么一个是新代码，一个是老代码呢？
 显然这是tomcat的缓存代码，需要清理tomcat的缓存，清理tomcat缓存，观察后台日志，发现问题解决！
 
 
 总结: 最后排查下来发现问题很简单，就是tomcat的缓存，其实问题很简单，但是这个问题本人却排查了一天半，排查过来是繁琐的，但是结果却是美好的，
 总算排查出来解决了。但是仔细回想，如果不一步步定位问题，谁又能一下子确认具体问题所在呢，排查问题就是经验累积的过程，相信下次在碰到这类奇葩问题，
 定位问题应该更快了。不管怎样，这次排查问题虽历时时间长，但是从中获取的经验还是很多的，感觉吃了一块大肉！！