微服务的隔离和熔断机制

1、微服务故障背景

       假设Tomcat线程池有100个线程， 每次有新的用户请求过来，Tomcat就会从中找出一个空闲的线程去执行， 抛开那些琐碎的小细节，这些请求其实非常简单， 无非就是这么几件事： 

1. 根据用户ID调用用户服务， 获取用户对象。 
2. 获取该用户的推荐商品 
3. 获取该用户的积分。 
4. 把这些信息组合起来，返回给浏览器。  

有意思的是前三件事情全是HTTP调用，需要调用某个地方的所谓“微服务”：

        比如线程A执行到“推荐服务”时，推荐服务没有立刻返回，导致推荐服务挂起，随着新用户请求的增加，线程池被耗完，那么Tomcat只能“系统繁忙、暂停营业”。虽然重启可能暂时解决问题，但问题可能还会重现。

2 隔离

      怎么把一个微服务的故障给隔离起来呢？让他们互不影响呢？

      Netflix的程序员们想了一个点子， 对每个微服务，都分配一个线程池，像这样： 

       比如说调用“推荐服务”的时候，就会从“推荐服务线程池” （假设有5个线程）中找到一个线程执行。如果这个HTTP系统调用迟迟没有返回，那这个线程就会一直等待，新的请求就需用使用池中别的线程。 

      如果5个“推荐服务”线程被耗光，可以人为这个服务不可用，需立即返回。

       这些新的线程池，是一种隔离的手段， 一个微服务一旦出了问题，很快就会被识别出来。    

3 熔断

        所以Netflix的程序员又想了一个办法：使用熔断器（也叫断路器），注意：当这个熔断器关闭的时候，外面的请求可以直接调用，如果打开，就把外界的请求给阻断了。  

具体的做法：系统会检测请求失败的比率（失败数/总请求数）， 一旦这个比率达到一个阈值的时候，熔断器就开启， 直接拒绝执行用户请求。然后休眠一段时间，尝试放过一部分流量（比如一个请求），如果调用成功，熔断器闭合，恢复到正常状态，否则继续进行休眠周期。 

熔断机制状态转移图如下：

主要在三种状态中转换：
关闭状态 ：当熔断器处于关闭状态时，请求是可以被放行的； 
                   当熔断器统计的失败次数触发开关时，转为打开状态。
打开状态 ：当熔断器处于打开状态时，所有请求都是不被放行的，直接返回失败； 
                   只有在经过一个设定的时间窗口周期后，熔断器才会转换到半开状态
半开状态 ：当熔断器处于半开状态时，当前只能有一个请求被放行； 
                   这个被放行的请求获得远端服务的响应后，假如是成功的，熔断器转换为关闭状态，否则转换到打开状态。