SpringCloud Part Four: Fuse Hystrix

Posted Jun 28, 20205 min read

1. Fuses

Service avalanche

Under the normal microservice architecture system, a business rarely needs to return data only by calling a service. This is more common in demos, and there are generally call chains, such as A->B ->C->D, if D has a problem at a certain moment, such as network fluctuations, io is high, resulting in stuttering, as time goes by, subsequent traffic continues to request, which will cause the pressure of D to rise, which may cause Downtime.
(Understanding the source code + request:1791743380)

Do you think this is the end? The pattern is broken. This is the beginning of a nightmare. The three services of ABC on the same call chain will cause downtime with the downtime of D. This is not the end. One service does not There may be only one interface. When it starts to freeze and down, it will affect the normal invocation of other invocation chains and eventually lead to the paralysis of all services.

As shown below:

SpringCloud Series Tutorial | Part 4:Fuse Hystrix

( https://springcloud-oss.oss-c... )

Fuse

I believe everyone knows home electric switches. The old-fashioned electric switches used fuses(a lot of them are now air switches). When the electricity consumption at home is too large, the fuses are often blown out. This is to protect the household electrical appliances and prevent overload.

The function of the fuse is very similar to this. It can achieve rapid failure. If the service call fails or is abnormal for a period of time, it will force the current call to fail, instead of taking the remote call, and taking the service downgrade operation(returning fixed data or some other downgrade) operating). This prevents the application from continuously trying to perform operations that may fail, allowing the application to continue to execute without waiting for the error to be corrected, or wasting CPU time waiting for a long timeout to occur. The fuse can also automatically diagnose whether the error has been corrected. If it has been corrected, the application will try to call the operation again.

The fuse mode is like an agent that is prone to erroneous operation. This agent can record the number of errors in the most recent call, and then decide to allow the operation to continue, or return the error immediately. Hystrix will have a fuse time window, the specific conversion logic is as follows:

SpringCloud Series Tutorial | Part 4:Fuse Hystrix

( https://springcloud-oss.oss-c... )

Fuses are the last line of defense for high availability of protection services.

2. Hystrix

1. Circuit breaker mechanism

The circuit breaker is well understood. When the number of Hystrix Command requests for back-end service failure exceeds a certain percentage(default 50%), the circuit breaker will switch to the open state(Open). At this time, all requests will fail directly 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), it automatically switches 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 state(CLOSED), otherwise it will switch back to the open state(OPEN). The Hystrix circuit breaker is like a 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 the query operation, we can implement a fallback method. When an exception occurs in the request back-end service, the value returned by the fallback method can be used. The return value of the fallback method is generally the default value set or from the cache.

3. Resource isolation

In Hystrix, resource isolation is mainly achieved through thread pools. Usually when we use it, we will divide multiple thread pools according to the remote service called. For example, the command to call the product service is put into the A thread pool, and the command to call the account service is put into the B thread pool. The main advantage of this is that the operating environment is isolated. In this way, even if the code that calls the service has bugs or the thread pool where it is located is exhausted due to other reasons, it will not affect other services of the system. But the cost is that maintaining multiple thread pools will bring additional performance overhead to the system. If you have strict performance requirements and you are sure that the client code that you call the service will not go wrong, you can use Hystrix's Semaphores to isolate resources.

3. Feign Hystrix

In the previous article, we used producers and consumers, and the fuse only acts on the service call end. Therefore, the consumers used in the previous article can be used directly. Because Feign already relies on Hystrix, there is no need to make any changes in the maven configuration.

1. New configuration file application.yml

server:
  port:8081
spring:
  application:
    name:spring-cloud-consumers
eureka:
  client:
    service-url:
      defaultZone:http://localhost:8761/eureka/
feign:
  hystrix:
    enabled:true

Added feign.hystrix.enabled = true

2. Create fallback class, inherit and implement callback method with 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:inwsy@hotmail.com
 * Description:
 */
@Component
public class HelloRemoteFallBack implements HelloRemote {
    @Override
    public String hello(@RequestParam(value = "name") String name) {
        return "hello "+ name + ", i am fallback massage";
    }
}

3. Add fallback attribute

Add the specified fallback class in the HelloRemote class, and return the content in the fallback class when the service is broken.

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);
}

All changes are complete.

4. Test

Now let's test to see the results, the old rules, start the registration center Eureka, provider, consumer in sequence

Visit the link we visited in the previous section: http://localhost:8081/hello/spring

Now you can see the page displays normally:hello spring, producer is ready

Now we manually stop the provider, and then visit the link to see:

Now the page has displayed the information after our fuse:hello spring, i am fallback massage

Now that our test has been successful.