微服务熔断机制 Hystrix_微服务熔弹

1、关于Spring Cloud - Hystrix

 
主要功能：

1. 服务降级.
2. 服务熔断.
3. 依赖隔离.
4. 监控.

1、服务降级：

• 优先核心服务，非核心服务不可用或弱可用

• 通过 HystrixCommand 注解指定
• fallbackMethod (回退函数)中具体实现降级逻辑

抛异常也可以触发降级。

注意降级，超时时间的配置，根据不同的业务设置服务间调用超时时间。

2、依赖隔离

• 线程池隔离
  会为每个HystrixCommand创建一个独立的线程池，不会影响拖慢其他依赖服务。

2、服务熔断

服务熔断：也称为服务隔离或过载保护。

       在微服务应用中，服务存在一定的依赖关系，形成一定的依赖链（例如：服务A的接口，可供外部客户端调用，同时也可被微服务体系中，服务B进行调用），如果某个目标服务调用慢或是有大量的超时，造成服务不可用，间接导致其他的依赖服务不可用，最严重的可能会堵塞整条依赖链，以至于导致业务系统崩溃（也就是所谓的雪崩效应）。
 
       此时，对该服务的调用执行熔断，对于后续请求，不在继续调用该目标服务，而是直接返回，从而可以快速释放资源。等待目标服务情况好转，则可恢复其调用。

        断路器可以用于日志记录，一个断路器应记录所有失败的请求，以使管理员能够监视它封装下受保护操作的运行状态。

 

3、熔断与降级

 

3.1 熔断和降级相同点

• 目的一致。两者都是从可用性、可靠性出发，为防止系统的整体缓慢甚至崩溃而采用的技术手段。
• 表现类似。两者最终表现都是，让用户体验到某些服务暂时不可达或不可用。
• 粒度一致。一般都是服务级别，服务熔断一般都是服务基于策略的自动触发，服务降级虽说可人工干预，但是微服务架构加，完全靠人显然不现实，所以会纳入自动化配置。

 

3.2 熔断与降级的区别

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

4、关于 Hystrix

        Hystrix 是 Netflix公司的一个开源项目，他提供了熔断功能，能够阻止分布式系统中出现联动故障。Hystrix 是通过隔离服务的访问点，阻止联动故障的，并提供了故障的解决方案，从而提高了整个分布式系统的弹性。
 
Hystrix 在微服务体系中的使用：

 

4.1 Hystrix 的设计原则

 
Hystrix 的设计原则如下：

• 防止单个服务的故障耗尽整个服务的Servlet容器（例如 Tomcat）的线程资源。
• 快速失败机制，如果某个服务出现了故障，则调用该服务的请求快速失败，而不是线程等待。
• 提供回退（fallback）方案，在请求发生故障时，提供设定好的回退方案。
• 使用熔断机制，防止故障扩散到其他服务。
• 提供熔断器的监控组件 Hystrix Dashboard，可以实时监控熔断器的状态。
   

4.2 Hystrix 的工作机制

        如上图，当服务的某个API接口失败次数在一定时间内小于设定的阀值时，熔断器处于关闭状态，该API接口正常提供服务。
 
        当该API接口处理请求的失败次数大于设定的阀值时，Hystrix 判定该API接口出现了故障，打开熔断器，此时请求该API接口会执行快速失败的逻辑（即fallback回退的逻辑），不执行业务逻辑，请求的线程不会处于堵塞状态。
 
        处于打开状态的熔断器，一段时间后会处于半打开状态，并将一定数量的请求执行正常逻辑。剩余的请求会执行快速失败，如果执行正常逻辑的请求失败了，则熔断器继续打开；如果成功了，则将熔断器关闭。这样熔断器就具有了自我修复能力。

 

4.3 如何集成 Hystrix

// 代码待更新 todo……
 

4.4 使用 Turbine 聚合监控

        在使用 Hystrix Dashboard 组件监控服务的熔断器状况时，每个服务都有一个 Hystrix Dashboard 主页，当服务数量很对时，监控会变得非常不方便。为了同时监控多个服务的熔断器的状况，Netflix 开源了 Hystrix的另一个组件 Turbine. Turbine用于聚合多个 Hystrix Dashboard，将多个 Hystrix Dashboard 组件的数据放在一个页面上展示，进行集中监控。

// Turbine 组件使用示例，代码待更新……