问题：周一出现生产问题，服务cps-service报死锁，adm-service报线程池耗尽。adm宕掉之后，2个小时无法做交易。
分析：初步分析，DBA并没有发现表锁，可能是adm-service超时超过50s之后，cps-service有提交事务，超过mysql配置的最大50s的时间，所以抛出死锁，但是唯一的困惑是，Dubbo服务默认时间为1s，cps不可能等待adm50s
操作：之后在压测环境进行测试，adm设置线程池数为2，目的让adm的线程池耗尽，之后10个线程发请求，adm报线程池耗尽错误，cps未报出死锁；之后将adm服务sleep50s，之后发送请求，发现，cps调用adm会一直等待50s后，也就是说dubbo的默认超时时间没有生效，之后需要排查为什么Dubbo设置超时时间失效。
查看源码发现，DubboInvoker类中，如果没有设置，默认时间是1秒。
简单的排查没有发现问题，之后想到，dubbo注册再zk上的url连接中，有timeout的设置时间，打开zk，拿到该服务，consumer和provider的注册url，timeout为180秒，之后在项目中搜索180秒，找到错误原因，CPS引用了bmp的xml，该xml配置了consumer的超时时间为180秒
