声明：本文仅做个人的一次接口重构过程记录，期间参考了一些写的不错的博客，如果存在抄袭，请留言。
hystrix基本介绍
hystrix 是一个开源的容灾框架，解决当依赖服务出现故障或者接口响应时间较慢，拖慢调用方业务系统，甚至引起系统雪崩的问题。
实际hystrix应用场景介绍
现在大部分应用系统都是采用的分布式框架，系统中会有很多的依赖，HTTP、Dubbo、hession等等，在高并发场景下，这些依赖的服务稳定性对系统的影响很大，当依赖阻塞时,大多数服务器的线程池就出现阻塞(BLOCK),影响整个线上服务的稳定性，如果没有对依赖的服务做隔离就会出现这样的场景:
某次大直播中（我是做直播的）通过监控发现某个接口RT猛增，通过pinpoint发现是依赖的一个接口响应时间比平时慢了很多，分析问题，该接口RT增加可能是因为依赖的下层接口响应时间增加，大量请求都阻塞在接口调用处，还有个问题，该接口的dubbo超时时间设置的1秒，1秒，1秒。。。。那这个接口影响1.2秒一点不奇怪，依赖接口都执行了1秒，问题分析到，接下来就是进行优化了。
优化过程
由于代码是别的同学写的，接口优化又迫在眉睫，上面只是举例其实还有别的问题，只是说明一下应用场景，根据实际情况我做了一个代码优化的方案
阶段一：不改变原有逻辑的情况下，尽可能少动，因为这个接口属于核心接口一旦出现问题可能影响较大（灰度发布的事，这里先不提，以后有时间会专门做一项关于灰度上线，灰度测试等，保证上线不影响的文档）