服务熔断、隔离、降级、限流等

服务熔断、隔离、降级、限流

1）熔断机制

    我们在各种场景下都会接触到熔断这两个字。高压电路中，如果某个地方的电压过高，熔断器就会熔断，对电路进行保护。股票交易中，如果股票指数过高，也会采用熔断机制，暂停股票的交易。同样，在微服务架构中，熔断机制也是起着类似的作用。
    熔断机制是为了避免服务器产生雪崩效应而产生的一种微服务链路保护机制。在高并发的情况下，流量超出了设置的阈值，或者当服务器达到最大的承受能力之后，直接熔断外界对该服务模块的调用，即拒绝外界访问该服务。然后调用降级方法，返回给用户一个友好提示。之后当检测到流量恢复正常后，再恢复外界对该服务模块的调用。
     熔断的目的：为了防止服务宕机(保护服务)，会进行熔断处理。
    熔断需要和服务降级一起使用。
----------------------------------------
熔断的原理和三种状态：
    Closed：熔断器关闭状态，调用失败次数积累，到了指定的阈值（或一定比例）后，则启动熔断机制；
    Open：熔断器打开状态，此时断掉外界对该服务模块的调用，即拒绝外界访问该服务，然后调用服务降级方法，返回给用户一个友好的提示。但还设计了一个时钟选项，当时钟达到了一定的时间后（这个时间一般设置成平均故障处理时间，也就是MTTR），熔断器进入半熔断状态；
    Half-Open：半熔断状态，允许一定量的请求 尝试调用该服务，如果都调用成功了（或一定比例成功了），则认为服务恢复正常了，于是关闭熔断器。反之认为服务还没恢复好，熔断器再次返回为打开状态；

2）服务降级

    当服务器压力骤增的情况下，根据当前业务情况及流量，对一些非核心的服务进行有策略的降级，以此释放服务器资源，以保证核心服务的正常运行。
    比如淘宝双十一的情形下，淘宝采用部分服务不出现、或者延时出现的手段，就是服务降级。

3）服务隔离

    任何软件系统，故障都是不可避免的，并且大多数还是不可预测的，因此，我们只能去尽最大可能的缩小故障的范围。 
    在微服务架构中，将各个服务模块之间进行一定程度的隔离，能保证在有不可预测的故障发生时，有效的缩小故障范围。
    简单来说,就是当系统中某个服务或组件出现故障时，能隔离这些故障，并且能做到优雅地进行服务降级。
    举个例子就是： 将各个服务或组件类比成一个个的小岛一样，当某个小岛被火烧光了，不会影响到其他的小岛。

服务隔离的实现方式：线程池方式。
     线程池方式：相当于每个服务都有自己独立的小线程池，不同的小线程池之间互不影响，能够实现服务隔离。
     缺点：CPU内存开销较大。

4）服务限流

    举一个我们生活中的例子：一些热门的旅游景点，往往会对每日的旅游参观人数有严格的限制，为什么旅游景点要做这样的限制呢？  
    因为对于旅游景点而言，景点的服务资源有限，每日能服务的人数是有限的，如果放开了限制，景点的工作人员就会不够用，卫生情况也得不到保障，安全也有隐患，等等产生一系列问题。但由于景区名气大，来游玩的旅客络绎不绝，远超出了景区的承载能力，因此景区只好做出限制每日人员流量的举措。

    同理，在我们的系统中，服务限流也是这样的。 

    服务限流是指：当服务器的资源不够，不足以应对大量的高并发请求，我们为了保证系统能够正常的服务，而对系统进行流量限制或功能限制的一种方法。


服务限流一般有以下几种模式：


熔断机制：略；

服务降级：略；

延迟处理：
    这个模式需要在系统的前面设置一个流量缓冲池，将所有的客户端请求全部放进这个缓冲池中，不立即处理。然后后端业务处理程序从这个池子中取出请求依次处理。
    常见的可以用队列模式来实现。这就相当于用异步的方式去减少了服务器的处理压力，但是当流量较大时，缓冲池里的请求可能处理不及时，会有一定程度延迟。