架构必经之路2 - 熔断机制
项目中要做一个熔断机制，预防对第三方的接口调用压力太大。下面我介绍下项目中用到的熔断机制。
1.熔断检测机制
（1）请求call到backend后，首先判断熔断开关是否打开
（2）如果熔断开关已打开，则表明当前请求不能被处理
（3）如果熔断开关未打开，则判断时间窗口（判断统计错误率）是否已满
（4）如果时间窗口（判断统计错误率）未满，则请求桶（redis) 中的请求数加1
（5）如果返回的response 有异常，则失败桶（redis) 的失败数加1，如果返回的response没有异常，则成功桶（redis) 的成功数加1
（6）如果时间窗口（判断统计错误率）已满，则开始判断是否需要熔断
2.熔断算法
充要条件：
（1）请求总数 > 设定值X
（2）失败率 > 设定值Y
请求总数可以从请求桶redis 中获取到
失败率 = 失败数 ÷ 请求数 × 100%
当请求总数大于一定值，且失败率大于一定值时，则表示请求失败数太多了，需要熔断API请求
3.统计失败率的时间窗口
（1）每次请求，都会判断时间窗口是否已满（如5分钟），如果时间窗口已满，则重新开始计时，且清理请求数/成功数/失败数
（2）第一次开始的起始时间默认为当前时间。
4.熔断持续时间
（1）如果出现问题，可以将所有请求链路熔断掉，熔断恢复时间可以假定为1分钟，可以根据不同的环境进行调整
（2）熔断恢复时间没有根据环境来进行动态调整，比如网络差的时候，持续了很长时间网络都很差，这个时候，可以动态递增熔断时间
5.手动熔断
因为熔断是通过统计单位时间内的失败率来判断是否需要熔断的，而有时候我们需要快速切断请求链路，比如充值请求量太大的时候，导致很多订单都被退款，这个时候我们可以先熔断获取套餐接口，这样用户就拿不到套餐，就不能充值了。
6.总熔断检测开关
有时候我们不需要熔断检测，这个时候我们就需要一个总开关，打开总开关，则进行熔断检测，关闭总开关，则不进行熔断检测。
7.查看当前熔断的状态
我们做了熔断检测，但是需要check下是否work了，可以check下以下参数
8.还有哪些可以优化的？有哪些不足？以及您是否遇到熔断的坑？
作 者：
Jackson0714
出 处：http://www.cnblogs.com/jackson0714/
关于作者：专注于微软平台的项目开发。如有问题或建议，请多多赐教！
版权声明：本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接。
特此声明：所有评论和私信都会在第一时间回复。也欢迎园子的大大们指正错误，共同进步。或者直接私信我
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是作者坚持原创和持续写作的最大动力！
