1 Overview
Problems faced by distributed systems:
applications in a load distributed architecture have dozens of dependencies, and each dependency will inevitably fail at some point.
Service avalanche: When
calling between multiple microservices, suppose that microservice A calls microservice B and microservice C, and microservice B and microservice C call other microservices. This is the so-called "fan-out". If the call response time of a microservice on the fan-out link is too long or unavailable, the call to microservice A will occupy more and more system resources, which will cause the system to crash, the so-called "avalanche effect."
For high-traffic applications, a single back-end dependency may cause all resources on all servers to be saturated within a few seconds. Worse than failure, these applications may also cause increased latency between services. The backup queues, threads, and other system resources are tight, causing more cascading failures in the entire system. These all mean that faults and delays need to be isolated and managed so that the failure of a single dependency cannot cancel the entire application or system. Therefore, usually when you find that an instance of a module fails, this module is still It will receive traffic, and then the module in question also calls other modules. This will cause a cascading failure, or avalanche.
1.1 What is
Hystrix is an open source library used to deal with the delay and fault tolerance of distributed systems. In distributed systems, many dependencies will inevitably lead to call failures, such as timeouts, exceptions, etc. Hystrix can guarantee that in the case of a dependency problem, no It will cause the overall service to fail, avoid cascading failures, and improve the resilience of the distributed system.
The "circuit breaker" itself is a kind of switching device. When a service unit fails, through the fault monitoring of the circuit breaker (similar to a blown fuse), an alternative response (FallBack) that meets expectations and can be processed is returned to the caller. , Instead of waiting for a long time or running out of exceptions that cannot be handled by the calling method, this ensures that the thread of the service caller will not be occupied for a long time and unnecessary, thus avoiding the spread of faults in the distributed system, and even avalanche.
1.2 What can you do
- Service degradation
- Service fusing
- Near real-time monitoring
- …
Official website information: https://github.com/Netflix/Hystrix/wiki/How-To-Use
2. Important concepts of Hystrix
2.1 Service degradation
The server is busy, please try again later, do not let the client wait and immediately return a friendly prompt, fallback.
The following conditions will trigger a downgrade:
- The program runs abnormally
- time out
- Service fuse triggers service degradation
- Full thread pool/semaphore will also cause service degradation
2.2 Service fusing
After the analog fuse reaches the maximum service access, it directly denies access, cuts off the power supply, and then calls the service downgrade method and returns a friendly prompt.
Service degradation -> then fuse -> restore the call link
2.3 Service current limit
Spike high concurrency and other operations, it is strictly forbidden to come over crowded in a swarm, everyone line up, N per second, and proceed in an orderly manner.