背景
功能冒烟演示的时候，发现一个接口的返回时候有时会执行5秒才返回，被测试提了一个问题。这个接口是我负责，所以需要我去处理。
过程
一开始，我不知道如何入手，于是我在一些可能会导致耗时的代码前后加上了log日志，打印耗时（比如http调用，mysql操作）。
然后被pm说了，他说可以通过“听云”查看接口性能。
我去，还有这么牛逼的系统吗！
登录"听云"后，我找到了我那个接口，可以看到io网络、code、sql、nosql的耗时，真的很牛逼。
回到正题，这个接口耗时5秒多，有5秒是耗费在了一个方法调用上（远程调用）。于是我就兴冲冲拍板，心想直接把这个调用改成异步不就得了！
我将这个远程调用方法改成了异步，然后提交代码。不久pm跟我说，你这样改，项目都被你改崩了。
我想：我去？异步还能崩？
pm：”这个远程调用，占了5秒，你整个接口耗时才5秒多，你即使把整个远程调用异步，你最多节省一百毫秒，这能解决问题吗？“
我想：”有道理啊，我这个蠢蛋！“
pm：”这个调用涉及到zookeeper单机，且服务器性能都很差，所以调用会很慢，你可以把它改成feign调用就好了！“
我想：”牛逼！“
总结
接口性能优化，我们本能会想到
- 现状：压测目前接口性能吞吐（知道性能到底多差）
- 定位：哪个步骤导致性能低
- 解决：针对问题进行解决
- 回归：重新压测，确认是否已经改好
其中解决的手段就是异步、缓存。
但我这次的问题就是异步、缓存都无法解决的，因为这个问题的耗时，占用整个接口耗时的99%。
有时候我们要多想！
