Springboot: 2.1.6. RELEASE

SpringCloud: Greenwich.SR1

Unless otherwise noted, the above versions are used for this series of tutorials

1. The fuse

Service avalanche

Under the normal micro service architecture of the system, A few only need to call A business service can return data, this is more common in the demo, there are generally call chain, such as A – > B > C – > D, if D at A certain moment problems, such as network fluctuations, IO on the high side, cause caton, with the passage of time, Subsequent traffic requests will increase the pressure of D, which may cause outage.

What do you think this is the end, a pattern in Tucson, it is the beginning of the nightmare, in the same call ABC three services will be on the chain with the outage of D triggered downtime, this also is not the end, a service can’t be only one interface, when it began to caton is down, will affect the other normal call invocation chain, eventually lead to all services.

As shown below:

fuse

I’m sure you all know about home switches. The old ones used fuses (many of which are now air switches). They often blew out when a home was using too much electricity to protect its appliances from overloading.

A fuse is similar in that it can fail quickly. If a service call fails or fails within a certain period of time, it will force the current call to fail, not to make a remote call, and to make a service degrade operation (return fixed data or some other degrade operation). This prevents the application from constantly trying to perform an operation that might fail, allowing the application to continue execution without waiting for an error to be fixed, or wasting CPU time waiting for a long timeout to occur. The fuse can also automatically diagnose whether the error has been fixed, and if so, the application will try to invoke the operation again.

Fuse mode acts as a proxy for error-prone operations. This proxy can record the number of times an error occurred in the most recent call, and then decide to use either allow the operation to continue or return an error immediately. Hystrix will have a fusing time window, the conversion logic is as follows:

Fuses are the last line of defense for high service availability.

2. Hystrix

1. Circuit breaker mechanism

Circuit breakers are easy to understand. When the number of Hystrix Command requests to the back-end service fails exceeds a certain percentage (50% by default), the circuit breaker switches to the Open state. All requests will fail and will not be sent to the back-end service. After the circuit breaker remains OPEN for a period of time (5 seconds by default), it automatically switches to half-open. The return of the next request is determined. If the request is successful, the breaker switches back to the CLOSED state, otherwise it switches back to the OPEN state. Hystrix’s circuit breakers are like the fuses in our home circuits. If the back-end service becomes unavailable, the circuit breaker directly cuts off the chain of requests, avoiding the throughput impact of sending a large number of invalid requests, and the circuit breaker has the ability to detect and recover itself.

2. Fallback

A Fallback is a degraded operation. For query operations, we can implement a fallback method to use the value returned by the fallback method in case of an exception to the request back-end service. The return value of the fallback method is usually the default value set or from the cache.

3. Resource isolation

In Hystrix, resource isolation is primarily achieved through thread pools. It is usually used to split multiple thread pools based on the remote service being called. For example, commands calling product services go into thread pool A and commands calling account services go into thread pool B. The main advantage of this is that the runtime environment is isolated. This will not affect other services in the system if the code calling the service is buggy or its thread pool is exhausted for some other reason. However, the trade-off is that maintaining multiple thread pools imposes additional performance overhead on the system. Hystrix’s Semaphores can be used to isolate resources if you are performance-critical and you are confident that the client code that you call the service will not cause problems.

3. Feign Hystrix

In the previous article, we used producer and consumers. Fuses are only applied to service invocators, so we can use the consumers used in the previous article directly. Because Feign already relies on Hystrix, there are no changes to the Maven configuration.

1. The application. Yml configuration file is added

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

Feign.hystrix. enabled = true is added

2. Create fallBack class that inherits callback methods from 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: [email protected]
 * Description:
 */
@Component
public class HelloRemoteFallBack implements HelloRemote {
    @Override
    public String hello(@RequestParam(value = "name") String name) {
        return "hello " + name + ", i am fallback massage"; }}Copy the code

3. Add the Fallback attribute

Add the specified Fallback class to the HelloRemote class to return the contents of the Fallback class in case of a service meltdown.

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);
}
Copy the code

All changes are complete.

4. Test

Now let’s test the result. As usual, start the registry Eureka, Provider, and Consumer in sequence

Access in the previous section we visited links: http://localhost:8081/hello/spring

Now the page displays: Hello Spring, producer is ready

Now let’s stop the provider manually and visit the link again to see:

The page now shows our fusing message: Hello Spring, I am Fallback Massage

That means our test has been successful.

Ok, now you can pack up the code and throw it on Github 🙂

Example code -Github

Reference:

Part5: using Hystrix, Hystrix Dashboard and Turbine in microservice systems