微服务的隔离和熔断机制

1、微服务故障背景

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

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

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

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

2 隔离

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

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

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

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

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

3 熔断

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

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

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

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