Avalanche effect
In the microservice architecture, there are usually multiple service layer calls. The failure of the basic service may cause This phenomenon is called the service avalanche effect. Service avalanche effect is a process in which the unavailability of “service consumers” due to the unavailability of “service providers”, and the unavailability is gradually enlarged.
As shown in the figure below: A is the service provider, B is the service consumer of A, and C and D are the service consumers of B. The unavailability of A causes the unavailability of B, and when the unavailability is enlarged to C and D like a snowball, the avalanche effect is formed.
CircuitBreaker
The principle of a fuse is very simple, just like an electrical overload protector. It can achieve rapid failure. If it detects many similar errors within a period of time, it will force multiple subsequent calls to fail quickly and no longer access the remote server, thereby preventing the application from constantly trying to perform operations that may fail , So that the application can continue to execute without waiting to correct errors, or waste CPU time to wait until a long timeout occurs. The fuse can also enable the application to diagnose whether the error has been corrected, and if it has been corrected, the application will try to call the operation again.
The fuse mode is like a proxy for operations that are prone to errors. This kind of agent can record the number of errors in the most recent call, and then decide to use the allow operation to continue, or immediately return the error. The logic of the fuse switch conversion is as follows:
The fuse is the last line of defense to protect the high availability of services.
Hystrix features
1. Circuit breaker mechanism
The circuit breaker is well understood. When Hystrix Command requests back-end service failure, the number of failures exceeds A certain percentage (default 50%), the circuit breaker will switch to the open state (Open). At this time, all requests will directly fail and will not be sent to the back-end service. After the circuit breaker remains in the open state for a period of time (default 5 seconds), Automatically switch to the half-open state (HALF-OPEN). At this time, the return of the next request will be judged. If the request is successful, the circuit breaker will switch back to the closed circuit state (CLOSED), otherwise it will switch back to the open circuit state (OPEN). Hystrix’s open circuit The circuit breaker is like the fuse in our home circuit. Once the back-end service is unavailable, the circuit breaker will directly cut off the request chain to avoid sending a large number of invalid requests to affect the system throughput, and the circuit breaker has the ability to self-detect and recover.
2.Fallback
Fallback is equivalent to a downgrade operation. For query operations, we can implement a fallback method. When an exception occurs in the back-end service request, the value returned by the fallback method can be used. The fallback method The return value of is generally the default value set or comes from the cache.
3. Resource isolation
In Hystrix, resource isolation is mainly achieved through thread pool. Usually when we use it, we Multiple thread pools are divided according to the remote service called. For example, the Command that calls the product service is placed in the A thread pool, and the Command that calls the account service is placed in the B thread pool. The main advantage of this is that the operating environment is isolated. This way Even if there is a bug in the code that calls the service or the thread pool in which you are in is exhausted due to other reasons, it will not affect the other services of the system. But the cost is that maintaining multiple thread pools will bring additional performance to the system Cost. If you have strict requirements on performance and you are sure that the client code that calls the service will not cause problems, you can use Hystrix’s signal mode (Semaphores) to isolate resources.
Implementation
In the previous article, Feign was used to implement the invocation of the services in it. Feign’s invocation method is more convenient and easier to understand.
Next, we need to make a fuse for spring cloud. To put it bluntly, we will do an exception handling for the service. When the provider has a problem, the node is down and cannot be accessed.
, To prevent the avalanche effect, leading to cluster paralysis. We only need to transform the service caller Consumer.
Because of Feign and Hystrix support, there is no need to import new dependencies.
application.yml Turn on the fuse
hystrix:
enabled: true
MessageRemoteHyx.java fuse inherits Feign’s calling interface p>
@Component
public class MessageRemoteHyx implements MessageRemote{
@Override
public Map hello() {
Map map=new HashMap();
map.put("message","hello world is error!!< /span>");
return map;
}
}
Add to the MessageRemote interface
fallback = MessageRemoteHyx.class
@FeignClient(name = "PROVIDER",fallback = MessageRemoteHyx.class)
public interface MessageRemote {
@RequestMapping(value = "/provider/hello ")
Map hello();
}
First call the HelloWorld service normally through Feign
Now manually close the Provider and call it again
After restarting the Provider, it will take a while (by default, after 5 seconds, turn on Half-open state, try to access the service, if successful, close the fuse)
feign:
hystrix:
enabled: true
@Component
public class MessageRemoteHyx implements MessageRemote{
@Override
public Map hello() {
Map map=new HashMap();
map.put("message","hello world is error!!< /span>");
return map;
}
}
@FeignClient(name = "PROVIDER",fallback = MessageRemoteHyx.class)
public interface MessageRemote {
@RequestMapping(value = "/provider/hello ")
Map hello();
}