(Forty) spring cloud micro-architecture b2b2c e-commerce service - service fault-tolerant protection (Hystrix service degradation)

Please add source e-commerce platform Penguin beg: 3536247259. Before you start using Spring Cloud Hystrix achieve breaker, something we acquire as a basis prior to implementation, including:

eureka-server projects: the service registry, port: 1001

eureka-client project: service providers, are two examples of start port 2001

Now we can copy it prior to implementation of a consumer service: eureka-consumer-ribbon, named eureka-consumer-ribbon-hystrix. Here we begin to change them at:

Step: Dependencies node pom.xml introduced in spring-cloud-starter-hystrix dependency:

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

Step 2: Use @EnableCircuitBreaker @EnableHystrix annotation application or main class of open Hystrix used:

@EnableCircuitBreaker
@EnableDiscoveryClient
@SpringBootApplication
public class Application {

	@Bean
	@LoadBalanced
	public RestTemplate restTemplate() {
		return new RestTemplate();
	}

	public static void main(String[] args) {
		new SpringApplicationBuilder(Application.class).web(true).run(args);
	}

}

Note: here we also can be modified using @SpringCloudApplication Main Class Spring Cloud applications annotation, the annotation shown specifically defined below. We can see that the annotation contains notes on our three cited, this also means that a standard application should include Spring Cloud service discovery and circuit breakers.

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

The third step: the transformation of service consumption patterns, new ConsumerService class, then the logical migration in the Controller's past. Finally, on the specific function to perform logical increase @HystrixCommand annotation to specify the method to downgrade services, such as:

@RestController
public class DcController {

    @Autowired
    ConsumerService consumerService;

    @GetMapping("/consumer")
    public String dc() {
        return consumerService.consumer();
    }

    class ConsumerService {

        @Autowired
        RestTemplate restTemplate;

        @HystrixCommand(fallbackMethod = "fallback")
        public String consumer() {
            return restTemplate.getForObject("http://eureka-client/dc", String.class);
        }

        public String fallback() {
            return "fallback";
        }

    }

}

Let's look at some basic features to verify the above Hystrix brings. We are involved in the service first starts up, and then visit localhost: 2101 / consumer, then you can get a normal return, such as: Services: [eureka-consumer-ribbon-hystrix, eureka-client].

In order to trigger service degradation logic, we can be a service provider eureka-client logical add some delay, such as:

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

After the restart eureka-client, and then try to access localhost: 2101 / consumer, this time we will get returns a value: fallback. We from eureka-client console, you can see the results of the output of the service provider had to be returned, but due to the delay of 5 seconds before returning, while the service consumer triggers a service request timeout exceptions, service consumers through HystrixCommand comment specified logic execution degraded, so the results of the request to return the fallback. Such a mechanism of self-service served to protect the foundation, but also provides automatic switching of service degradation mechanism is abnormal.

Guess you like

Origin blog.csdn.net/wiyzq/article/details/90901839