（一）碎碎念接口优化--新代码提交问题

        今天改了一个慢接口问题，服务端响应时间超时，查看接口的响应时间近20s。首先声明解决这个问题和技术没有什么大关系，和技巧有关系吧，O(∩_∩)O~

过程

        1  、 发现接口慢首先不管三七二十一，先把线上的环境接口域名切换到staging环境地址（预发布环境），然后对改接口用到的各个dubbo项目的远程调试，从大的范围到小得范围改变断点，排除法，直到发现那个方法块执行慢，哪行代码执行慢。结果发现这行代码调用的是另一个dubbo项目，ucenter项目中的一个方法，跟踪到最后，发现主要原因是，1 业务逻辑有些复杂 2 有些业务逻辑写在sql中  3 改sql单条调用不是很慢，但是这个接口多次调用了，所以才会慢，通过查看听云，可以看到请求一次接口，这个sql就会被执行7次。

        改业务逻辑貌似不太现实，优化sql，一般是explain该条sql，发现并没有什么异常，索引也都建立，所以到了无济于事的地步了。

        2 、 到了山穷水尽的时候，这条sql的中还有一些业务逻辑，如果把业务逻辑放到java中，db中只执行简单的查询操作，修改也需要一段时间。从快速解决问题的角度来看，问题回到了原点，由于预发布环境有两套，在staing1 中访问接口，接口超时，但是发现在staging2中访问该接口，结果该接口的可以返回数据，大约2s左右返回数据，凑合的可以接受，开始有了点头绪。

        也就是说staging1和staging2 代码不同步，并不是一套代码，经查看编译时间，发现staging2中旧的版本，也就是改问题是因为这中间中修改了代码出现的问题。这样问题一下子定位到提交的新代码，可能提交的新的代码有问题。

        3 、git 查看commit history，发现for外面的一个方法被放到了for里面执行，恍然大悟，如果之前这个dubbo接口返回要500ms，要是循环10个，要5000ms，所以把for中的公共部分拿出来放到外面就好了。

        好吧，解决问题的过程，想任何可能出问题的地方，找出蛛丝马迹，try everything