Spring Cloud builds microservices architecture-hystrix service downgrade

In the micro-service architecture, we split the system into a single service unit, and each unit application is dependent on each other through the way of service registration and subscription. Since each unit runs in a different process and relies on a remote invocation, it is possible that a call failure or delay may occur due to network or dependent service problems that directly cause the caller's external service to be delayed, and if the caller's request is increasing at this time, Finally, there will be a backlog of tasks due to waiting for the failure of the relying party response, thread resources can not be released, resulting in the paralysis of their own services, and even the spread of further failures eventually lead to the overall system paralysis. If such a structure has such a serious hidden danger, it is more unstable than the traditional architecture. In order to solve such problems, a series of service protection mechanisms such as circuit breakers are produced.

To solve these problems, a series of service protection functions such as thread isolation, circuit breaker and so on are implemented in spring Cloud hystrix. It is also implemented by the Netflix-based open source framework Hystrix, which aims to provide greater fault tolerance for latency and failure by controlling the nodes that access remote systems, services, and third-party libraries. Hystrix has powerful features such as service degradation, service fuse, thread isolation, request caching, request merging, and service monitoring.

Next, let's start with a simple example of learning and using spring Cloud hystrix.

Before we start using Spring Cloud Hystrix to implement a circuit breaker, let's take some of the previously implemented content as a foundation, including:

Eureka-server Project: Service Registration Center, port: 1001
Eureka-client Project: Service provider, two instance boot ports are 2001
Below we can copy the previous implementation of a service consumer: Eureka-consumer-ribbon, named Eureka-consumer-ribbon-hystrix. Let's start by changing it to the following:

The first step: the introduction of Spring-cloud-starter-hystrix dependency in the Dependencies node of Pom.xml:

<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-hystrix</artifactId></dependency>

Step two: Use @enablecircuitbreaker or @enablehystrix annotations to turn on the use of Hystrix in the main class of the application:

@EnableCircuitBreaker@EnableDiscoveryClient@SpringBootApplicationpublic class Application {@Bean@LoadBalancedpublic RestTemplate restTemplate() {return new RestTemplate();}public static void main(String[] args) {new SpringApplicationBuilder(Application.class).web(true).run(args);}}

Note: Here we can also use the @springcloudapplication annotations in the spring cloud app to decorate the main class of the application, and the specific definition of the annotation is as follows. We can see that the note contains the three annotations we quoted, which also means that a spring cloud standard application should include service discovery and circuit breakers.

@Target({ElementType.TYPE})@Retention(RetentionPolicy.RUNTIME)@Documented@Inherited@SpringBootApplication@EnableDiscoveryClient@EnableCircuitBreakerpublic @interface SpringCloudApplication {}

Step Three: Transform the service consumption mode, add the Consumerservice class, and then move the logic in the controller into the past. Finally, add @hystrixcommand annotations to the function that specifically performs the logic to specify the service demotion method, for example:

@RestControllerpublic class DcController {@AutowiredConsumerService consumerService;@GetMapping("/consumer")public String dc() {return consumerService.consumer();}class ConsumerService {@AutowiredRestTemplate restTemplate;@HystrixCommand(fallbackMethod = "fallback")public String consumer() {return restTemplate.getForObject("http://eureka-client/dc", String.class);}public String fallback() {return "fallback";}}}

Let's examine some of the basic features of the hystrix above. We start with the services involved and then access Localhost:2101/consumer, where we can get a normal return, such as: services: [Eureka-consumer-ribbon-hystrix, Eureka-client].

To trigger the service demotion logic, we can add some delay to the logic of the service provider Eureka-client, such as:

@GetMapping("/dc")public String dc() throws InterruptedException {Thread.sleep(5000L);String services = "Services: " + discoveryClient.getServices();System.out.println(services);return services;}

After restarting Eureka-client, try to access Localhost:2101/consumer, and we will get the return result: fallback. We can see from the console of the eureka-client that the service provider outputs the results that were originally to be returned, but because the service consumer triggered a service request timeout exception due to a delay of 5 seconds before it was returned, the service consumer was executed by the downgrade logic specified in the Hystrixcommand annotation , so the result of the request returned fallback. Such a mechanism provides the basic protection for its own service, while providing an automatic service downgrade switching mechanism for abnormal situations.

From now on, I will record the process and the essence of the recently developed Springcloud micro-service cloud architecture, and help more friends who are interested in developing the Spring cloud framework, hoping to help more good scholars. Let's explore how the Spring cloud architecture is built and how it can be used in enterprise projects.
Source source technical support for complete projects 1791743380

Spring Cloud builds microservices architecture-hystrix service downgrade