Fuse
Avalanche
In the micro-services architecture usually have multiple service layer calls, failure of basic services could lead to cascading failures, and cause the entire system is unavailable, a phenomenon called avalanche effect service. Services avalanche effect is a result of "service provider" of unavailability "service consumer" is not available and unavailable gradually enlarge the process.
If it is shown below: as a service provider A, B is the service consumer A, C and D are B Service Consumers. A Not available due to unusable B, and is not available to an enlarged snowball C and D, the avalanche effect is formed.
Fuse (CircuitBreaker)
Fuse principle is very simple, as the power overload protection. It can be implemented quickly fail if it detects many similar errors over time, will force more quickly after calling it a failure, no longer access a remote server in order to prevent the application constantly try to execute the operation may fail so that the application continues to execute without waiting for error correction, or a waste of CPU time to produce a long wait for a timeout. Fuses can also enable an application to 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. Fuse switch logic conversion as shown below:
Fuse is the availability of protection services last line of defense.
Hystrix properties
1. The circuit breaker mechanism
Circuit breakers is well understood that, when a backend service request failed Hystrix Command quantity exceeds a certain percentage (default 50%), the circuit breaker will switch to an open state (Open). In this case all requests are not sent directly to the failure of the backend service the circuit breaker remains in an open state after a period of time (5 seconds by default) automatically switches to the half-open state (hALF-oPEN). in this case a request to return the situation will determine if the request is successful, the closed state of the circuit breaker switch back ( CLOSED), or switch back to the open state (oPEN). Hystrix circuit breaker is like our family in the fuse, once the back-end service is not available, the circuit breaker will cut off the direct chain of requests, to avoid sending a large number of invalid requests affect system throughput and circuit breakers have the ability to self-testing and recovery.
2.Fallback
Fallback相当于是降级操作. 对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值. fallback方法的返回值一般是设置的默认值或者来自缓存.
3.资源隔离
在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池. 例如调用产品服务的Command放入A线程池, 调用账户服务的Command放入B线程池. 这样做的主要优点是运行环境被隔离开了. 这样就算调用服务的代码存在bug或者由于其他原因导致自己所在线程池被耗尽时, 不会对系统的其他服务造成影响. 但是带来的代价就是维护多个线程池会对系统带来额外的性能开销. 如果是对性能有严格要求而且确信自己调用服务的客户端代码不会出问题的话, 可以使用Hystrix的信号模式(Semaphores)来隔离资源.
Feign Hystrix
因为熔断只是作用在服务调用这一端，因此我们根据上一篇的示例代码只需要改动spring-cloud-consumer项目相关代码就可以。因为，Feign中已经依赖了Hystrix所以在maven配置上不用做任何改动。
本帖转自：http://www.ityouknow.com/springcloud/2017/05/16/springcloud-hystrix.html
转载请注明出处！