把问题及调研结果全记录下来，尽量详细，避免节后重复造轮子。
本周开启falcon告警，频繁收到接口超时告警。
接口出现超时问题分析：平均超时量100+，对应性能日志统计平均耗时达到3秒+，最大7-9秒。
问题1）remote、provider正常运行，接口超时。非必现
问题2）remote重启，provider不做重启，接口超时。在remote层增加相关日志。必现
问题3）remote不重启，provider重启，接口超时。 必现
针对问题2）做了如下排查分析：
分析1. remote层service调用rpc前后增加性能日志，同一时段统计对应的Rpc调用耗时最大600ms，调用Rpc的设置的timeout是2秒，但是remote日志没有对应的RpcException异常抛出，同时调用Rpc超时跟remote本身统计的耗时也不吻合，那么remote层统计出的平均超时3秒+如何导致？？
分析2. remote中API进入和结束增加了日志超过2秒记录vid，调用Rpc前后增加日志超过500ms记录vid，当服务重启后会有100+的超过3秒+请求，但是此时RPC并没有对应日志，根据停止容器大概过程分析：resin停止后关闭Close web容器，销毁Bean，取消订阅，关闭Netty Channel，关闭ZK，关闭resin线程池，之后才调用了Dubbo的ShutdownHook，此时会出现Failed to unregister url，最后一步关闭了Dubbo连接。也就是说当resin未完全关闭情况下，部分请求已经被接收但是并没有被成功处理掉，导致超时。根据这个思路，那么我们应该自己去destroy掉Dubbo相关连接服务，在resin容器关闭之前执行。
发现自己分析问题的思路和部门其他人都不一样，而且没有把想法说明白的习惯。很多事情我虽然说过，但是其他人本来的思路也没在那个地方，说了其他人也没get，回来问题暴露出来，他们都不记得我说过。从头到尾，我就没有让别人了解其中的利弊。归根到底还是能力不足，没能让大家理解。这样自己有想法和没想法，结果是一样的，没有给部门带来任何好处。
自己本身的性格就是不谙世事，也不考察行情。相对自己的工作经验，自己目前的职级是很低的，因为来公司的时候对自己的定位就低。因为本身只想做好技术，也没有什么野心。但是最近跟正在创业的朋友们说如果他们需要替他们公司去参加技术大会做演讲的，可以找我。我这么低的职级，演讲都没有底气。前端时间去阿里面试，心里也是有这个考虑。但是想想我们老大人又聪明，情商又高，不舍得走啊。我都不知道人家怎么做到的，完全的知道我喜欢做什么不喜欢做什么。到底是人家太聪明，还是我太容易被看穿了【汗】。估计两者都有，不过像我这种性格从来都没有什么怀才不遇，不被理解这样的事情，挺好的。话说我们老大身上值得我学习的事情太多了，说话做事让人觉得特舒服，开着红色宝马车，响当当的男神一枚~~
最近手上的事情太多，太杂。尽快收敛总结一下。然后踏踏实实的把接口优化做好。来公司一年半了，都没真正为公司做出什么别人做不出的贡献，好事儿倒是一样都没把我落下。要走也得先做出些成绩了，不然良心会不安的。
原文：http://www.cnblogs.com/xiexj/p/6657410.html