[Spring Cloud] Hystrix fuse mechanism

foreword

What is the fuse of hystrix?

Hystrix fusing mainly means that within a certain time window, when the number of requests reaches a certain failure rate, hystrix will actively refuse the service and adopt methods such as directly downgrading the request, thereby effectively alleviating the problem of service avalanche. Through the fast error method, it can effectively control the response time of link calls between services and ensure the health of the entire microservice.

Configuration using hystrix fuse function

To enable hystrix fuse and configure hystrix timeout, you need to pay attention to the impact of ribbon timeout configuration. For details, please refer to the example in the hystrix request timeout configuration article.

//超时时间
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=2000
//开启熔断
hystrix.command.default.execution.timeout.enabled=true

//熔断触发的最小个数，即在一定的时间窗口内请求达到一定的次数，默认20
hystrix.command.default.circuitBreaker.requestVolumeThreshold=10
//时间窗口，默认10s
hystrix.command.default.metrics.rollingStats.timeInMilliseconds=5000
//失败率达到多少百分比后熔断 默认值：50
hystrix.command.default.circuitBreaker.errorThresholdPercentage=50
//熔断多长时间后，尝试放一次请求进来，默认5秒
hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds=5000

The above configuration indicates that within 5 seconds, if the number of requests reaches 10 and 50% of them fail, the fusing function will be enabled, and after the fusing function is enabled for 5 seconds, one request is allowed (that is, the fusing is in a half-open state at this time), if the request access is successful, the fusing is turned off, and the normal call is resumed, otherwise the fusing is continued for 5 seconds, and the cycle is repeated.

close state

When the condition is met, the circuit breaker opens

Three states of a circuit breaker:

1. Closed state
   In the closed state, the client's request can arrive normally.
2. Open state
   When the state is open, the client's request will not reach the server, and the downgrade method will be used directly.
3. Half-open state
   When the state is open, after a certain period of time, the fuse will change from open state to half-open state.
   At this time, it is possible to receive a request from the client. If the request is successful, the status of the fuse will be turned off. If the request fails, the status of the fuse will be turned on. Wait for the next time period to continue trying the service call.

How Hystrix works

Hystrix workflow

• Create a HystrixCommand or HystrixObservableCommand object
• Execute commands execute(), queue(), observe(), toObservable()
• If the request result caching feature is enabled and the cache hits, the cached response is immediately returned as an Observable
• Check the status of the fuse to determine whether the request line is open. If the request line is open, Hystrix will not execute this command, but directly execute getFallback
• If there is a thread pool and request queue associated with the current command that needs to be executed, Hystrix will not execute the command, but directly execute getFallback
• Execute HystrixCommand.run() or HystrixObservableCommand.construct(), if the execution of these two methods times out or fails, execute getFallback()
• Hystrix will report the success, failure, rejection or timeout information of the request to the fuse, and the fuse maintains some counters for statistical data. The statistical data generated by these counters enables the fuse to short-circuit a subsequent request of a dependent service at a specific moment until the recovery period ends. If the recovery period ends and the fuse determines that the line is still not healthy according to the statistical data, the fuse will close the line again.
• Dependency isolation Hystrix uses the bulkhead isolation pattern to isolate dependencies between each other and limit concurrent access to any one of them.
  Some people may have doubts, why not rely on the HTTP Client for fault-tolerant protection (fast failure, fuse, etc.), but make this circuit breaker (Hystrix) by means of thread & thread pool isolation outside of access dependencies`

Mainly the following aspects:

• Different dependencies have different execution frequencies and need to be treated separately
• Different dependencies may require different Client tools/protocols to access. For example, we may use HTTP Client or Thrift Client.
• Client may also have non-network exceptions during execution, which should be isolated
• The change of Client will cause the change of circuit breaker