微服务系列(六) 服务熔断与服务降级

一. 背景

分布式系统环境下，服务间类似依赖非常常见，一个业务调用通常依赖多个基础服务。如下图，对于同步调用，当库存服务不可用时，商品服务请求线程被阻塞，当有大批量请求调用库存服务时，最终可能导致整个商品服务资源耗尽，无法继续对外提供服务。并且这种不可用可能沿请求调用链向上传递，这种现象被称为雪崩效应。

二. 服务雪崩

在微服务之间进行服务调用是由于某一个服务故障，导致级联服务故障的现象，称为雪崩效应。雪崩效应描述的是提供方不可用，导致消费方不可用并将不可用逐渐放大的过程。

图解雪崩效应

如存在如下调用链路:

而此时，Service A的流量波动很大，流量经常会突然性增加！那么在这种情况下，就算Service A能扛得住请求，Service B和Service C未必能扛得住这突发的请求。此时，如果Service C因为抗不住请求，变得不可用。那么Service B的请求也会阻塞，慢慢耗尽Service B的线程资源，Service B就会变得不可用。紧接着，Service A也会不可用，这一过程如下图所示

雪崩效应常见场景

• 硬件故障：如服务器宕机，机房断电，光纤被挖断等。
• 流量激增：如异常流量，重试加大流量等。
• 缓存穿透：一般发生在应用重启，所有缓存失效时，以及短时间内大量缓存失效时。大量的缓存不命中，使请求直击后端服务，造成服务提供者超负荷运行，引起服务不可用。
• 程序BUG：如程序逻辑导致内存泄漏，JVM长时间FullGC等。 同步等待：服务间采用同步调用模式，同步等待造成的资源耗尽。

雪崩效应应对策略

针对造成雪崩效应的不同场景，可以使用不同的应对策略，没有一种通用所有场景的策略，参考如下：

• 硬件故障：多机房容灾、异地多活等。
• 流量激增：服务自动扩容、流量控制（限流、关闭重试）等。
• 缓存穿透：缓存预加载、缓存异步加载等。
• 程序BUG：修改程序bug、及时释放资源等。
• 同步等待：资源隔离、MQ解耦、不可用服务调用快速失败等。资源隔离通常指不同服务调用采用不同的线程池；不可用服务调用快速失败一般通过熔断器模式结合超时机制实现。

综上所述，如果一个应用不能对来自依赖的故障进行隔离，那该应用本身就处在被拖垮的风险中。 因此，为了构建稳定、可靠的分布式系统，我们的服务应当具有自我保护能力，当依赖服务不可用时，当前服务启动自我保护功能，从而避免发生雪崩效应。本文将重点介绍使用Hystrix解决同步等待的雪崩问题。

三. Histrix 使用

In a distributed environment, inevitably some of the many service dependencies will fail. Hystrix is a library that helps you control the interactions between these distributed services by adding latency tolerance and fault tolerance logic. Hystrix does this by isolating points of access between the services, stopping cascading failures across them, and providing fallback options, all of which improve your system’s overall resiliency.      –摘自官方

译: 在分布式环境中，许多服务依赖项不可避免地会失败。Hystrix是一个库，它通过添加延迟容忍和容错逻辑来帮助您控制这些分布式服务之间的交互。Hystrix通过隔离服务之间的访问点、停止它们之间的级联故障以及提供后备选项来实现这一点，所有这些都可以提高系统的整体弹性。

1. Histrix设计与实现

Hystrix [hɪst’rɪks]，中文含义是豪猪，因其背上长满棘刺，从而拥有了自我保护的能力。本文所说的Hystrix是Netflix开源的一款容错框架，同样具有自我保护能力,为了实现容错和自我保护，下面我们看看Hystrix如何设计和实现的。

Hystrix设计目标

• 对来自依赖的延迟和故障进行防护和控制——这些依赖通常都是通过网络访问的
• 阻止故障的连锁反应
• 快速失败并迅速恢复
• 回退并优雅降级
• 提供近实时的监控与告警

Hystrix遵循的设计原则

• 防止任何单独的依赖耗尽资源（线程）
• 过载立即切断并快速失败，防止排队
• 尽可能提供回退以保护用户免受故障
• 使用隔离技术（例如隔板，泳道和断路器模式）来限制任何一个依赖的影响
• 通过近实时的指标，监控和告警，确保故障被及时发现
• 通过动态修改配置属性，确保故障及时恢复
• 防止整个依赖客户端执行失败，而不仅仅是网络通信

Hystrix如何实现这些设计目标？

• 使用命令模式将所有对外部服务（或依赖关系）的调用包装在HystrixCommand或HystrixObservableCommand对象中，并将该对象放在单独的线程中执行；
  每个依赖都维护着一个线程池（或信号量），线程池被耗尽则拒绝请求（而不是让请求排队）。
• 记录请求成功，失败，超时和线程拒绝。
• 服务错误百分比超过了阈值，熔断器开关自动打开，一段时间内停止对该服务的所有请求。
• 请求失败，被拒绝，超时或熔断时执行降级逻辑。
• 近实时地监控指标和配置的修改。

2. 服务熔断和服务降级

服务熔断

“熔断器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控，某个异常条件被触发，直接熔断整个服务。向调用方法返回一个符合预期的、可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方法无法处理的异常，就保证了服务调用方的线程不会被长时间占用，避免故障在分布式系统中蔓延，乃至雪崩。如果目标服务情况好转则恢复调用。服务熔断是解决服务雪崩的重要手段。
服务熔断图示:

服务降级

服务压力剧增的时候根据当前的业务情况及流量对一些服务和页面有策略的降级，以此环节服务器的压力，以保证核心任务的进行。同时保证部分甚至大部分任务客户能得到正确的相应。也就是当前的请求处理不了了或者出错了，给一个默认的返回。
通俗: 关闭系统中边缘服务 保证系统核心服务的正常运行 称之为服务降级

服务熔断与服务降级对比

共同点

• 目的很一致，都是从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃，采用的技术手段；
• 最终表现类似，对于两者来说，最终让用户体验到的是某些功能暂时不可达或不可用；
• 粒度一般都是服务级别，当然，业界也有不少更细粒度的做法，比如做到数据持久层（允许查询，不允许增删改）；
• 自治性要求很高，熔断模式一般都是服务基于策略的自动触发，降级虽说可人工干预，但在微服务架构下，完全靠人显然不可能，开关预置、配置中心都是必要手段。

异同点

• 触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；
• 管理目标的层次不太一样，熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）。

总结

熔断必会触发降级,所以熔断也是降级一种,区别在于熔断是对调用链路的保护,而降级是对系统过载的一种保护处理。

3. 使用Histrix实现服务熔断

服务熔断的实现思路

• 引入hystrix依赖,并开启熔断器(断路器)
• 模拟降级方法
• 进行调用测试

项目中引入hystrix依赖

<!--引入hystrix-->
<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

开启断路器

在启动类上加入注解
@EnableCircuitBreaker //启用断路器
注意: 这里其实也可以使用 spring cloud应用中的@SpringCloudApplication注解，因为它已经自带了这些注解,源码如下:

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public @interface SpringCloudApplication {
   

}

加入注解

@SpringBootApplication
@EnableCircuitBreaker  //用来开启断路器
public class Products9998Application {
   
    public static void main(String[] args) {
   
        SpringApplication