Follow me SpringCloud | Part IV: Fuses Hystrix
1. Fuse
Avalanche Service
Under normal service micro-architecture system, a business case only rarely need to call a service can return data, which is more common appearance in the demo, usually there is a call chain, such as A-> B -> C-> D, D an instant if a problem occurs, such as network fluctuations, io high, resulting in Caton, over time, continue to follow the flow request will cause rise in pressure D, may cause downtime.
Do you think this is the end of it, breaking the pattern of Tucson, this is the beginning of a nightmare, ABC three services on the same call chain will be with the D of downtime caused downtime, this is not the end, not a service may be an interface when it starts Caton down, it will affect the normal call other call chain, eventually leading to paralysis of all services.
As shown below:
Fuse
I believe we all know that home gates, the gates is to use the original old-fashioned fuse (many of which are now switch the air), excessive use of electricity at home when the fuse blows frequently, to do so is to protect the home appliances to prevent overload.
The role of the fuse and the like, it can be quickly fail if the service call failure or abnormal period of time, will be mandatory for the current call fails, do not take the long-distance call, go service downgrade (or some other fixed data returned downgrade operating). Thereby preventing the application constantly trying to perform the operation may fail, making the application to continue without waiting for the error correction, or a waste of CPU time to produce a long wait for a timeout. Fuses can automatically diagnose whether an error has been corrected, if already amended application attempts to call the operation again.
Acting like a fuse mode operation of those error-prone. This agent is able to record the number of errors recent call occurs, then decided to use allows the operator to continue, or returns an error immediately. Hystrix have a fusing time window, specific conversion logic is as follows:
Fuse is the availability of protection services last line of defense.
2. Hystrix
1. The circuit breaker mechanism
断路器很好理解, 当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open)。这时所有请求会直接失败而不会发送到后端服务。断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN)。这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN)。Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力。
2. Fallback
Fallback相当于是降级操作。对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值。fallback方法的返回值一般是设置的默认值或者来自缓存。
3. 资源隔离
在Hystrix中, 主要通过线程池来实现资源隔离。通常在使用的时候我们会根据调用的远程服务划分出多个线程池。例如调用产品服务的Command放入A线程池, 调用账户服务的Command放入B线程池。这样做的主要优点是运行环境被隔离开了。这样就算调用服务的代码存在bug或者由于其他原因导致自己所在线程池被耗尽时, 不会对系统的其他服务造成影响。但是带来的代价就是维护多个线程池会对系统带来额外的性能开销。如果是对性能有严格要求而且确信自己调用服务的客户端代码不会出问题的话, 可以使用Hystrix的信号模式(Semaphores)来隔离资源。
3. Feign Hystrix
上一篇我们使用了producer和consumers，熔断器是只作用在服务调用端，因此上一篇使用到的consumers我们可以直接拿来使用。因为，Feign中已经依赖了Hystrix所以在maven配置上不用做任何改动。
1. 配置文件application.yml新增
server:
port: 8081
spring:
application:
name: spring-cloud-consumers
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka/
feign:
hystrix:
enabled: true其中新增了feign.hystrix.enabled = true
2. 创建fallback类，继承与HelloRemote实现回调的方法
package com.springcloud.consumers.fallback;
import com.springcloud.consumers.remote.HelloRemote;
import org.springframework.stereotype.Component;
import org.springframework.web.bind.annotation.RequestParam;
/**
* Created with IntelliJ IDEA.
*
* @User: weishiyao
* @Date: 2019/7/2
* @Time: 23:14
* @email: [email protected]
* Description:
*/
@Component
public class HelloRemoteFallBack implements HelloRemote {
@Override
public String hello(@RequestParam(value = "name") String name) {
return "hello " + name + ", i am fallback massage";
}
}
3. 添加fallback属性
在HelloRemote类添加指定fallback类，在服务熔断的时候返回fallback类中的内容。
package com.springcloud.consumers.remote;
import com.springcloud.consumers.fallback.HelloRemoteFallBack;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;
/**
* @Author: shiyao.wei
* @Date: 2019/7/2 11:14
* @Version: 1.0
* @Desc:
*/
@FeignClient(name= "SPRING-CLOUD-PRODUCER", fallback = HelloRemoteFallBack.class)
public interface HelloRemote {
@RequestMapping(value = "/hello")
String hello(@RequestParam(value = "name") String name);
}所有改动结束。
4. 测试
现在我们测试看下结果，老规矩，顺次启动注册中心Eureka、provider、consumer
访问上一节我们访问过的链接：http://localhost:8081/hello/spring
现在可以看到页面正常显示：hello spring，producer is ready
现在我们手动把provider停掉，再访问一下链接看一下：
现在页面已经显示我们熔断后的信息了：hello spring, i am fallback massage
现在说明我们的测试已经成功了。
好了，现在可以将代码打包扔到Github上去了：）
参考：
微服务框架Spring Cloud介绍 Part5: 在微服务系统中使用Hystrix, Hystrix Dashboard与Turbine