In the microservice architecture, we split the system into service units, and the applications of each unit depend on each other through service registration and subscription. Because each unit to run in different processes, relying on execution by means of remote calls, so it may be because the network reason or rely on the service itself problem call failure or delay, and these problems will directly lead to the caller’s foreign service also delays, if the caller’s request at this time continue to increase, Finally, the task backlog will be formed due to waiting for the response of the dependent party with failure, and the thread resources cannot be released, which will eventually lead to the paralysis of its own service, and further, the spread of the fault will eventually lead to the paralysis of the whole system. If such an architecture has such serious pitfalls, it will be more unstable than a traditional architecture. In order to solve this problem, a series of service protection mechanisms such as circuit breakers are produced.
To solve these problems, Spring Cloud Hystrix implements a series of service protection functions such as thread isolation and circuit breakers. It is also based on Hystrix, Netflix’s open source framework, which aims to provide greater fault tolerance for delays and failures by controlling those nodes that access remote systems, services, and third-party libraries. Hystrix has powerful features such as service degradation, service meltdown, thread isolation, request caching, request consolidation, and service monitoring.
Let’s start with a simple example to learn and use Spring Cloud Hystrix.
Give it a try
Before we start implementing circuit breakers using Spring Cloud Hystrix, we’ll start with some of the things we implemented earlier, including:
Eureka-server project: service registry with port 1001 eureka-client project: service provider with port 1001 eureka-client project: service registry with port 1001 eureka-client project: service provider with port 1001 eureka-client project: service registry with port 1001 Eureka-client project: service provider with port 1001 eureka-client Eureka-consumer-ribbon, named Eureka-consumer-ribbon-Hystrix. Let’s start to change it in:
Add the spring-cloud-starter-hystrix dependency to the dependencies section of PUM. XML:
Org. Springframework. Cloud spring – the cloud – starter – hystrix step 2: in the application of the main class using the @ EnableCircuitBreaker or @ EnableHystrix annotation open hystrix use:
@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 can also decorate the application main class with the @SpringCloudApplication annotation in the SpringCloud application, which is defined below. We can see that this annotation includes the three annotations we referenced above, which means that a Spring Cloud standard application should include service discovery and circuit breakers.
@Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @SpringBootApplication @enablecircuitbreaker public @Interface SpringCloudApplication {} Change the way the service is consumed, add the ConsumerService class, and then migrate the logic in Controller. Finally, add the @hystrixCommand annotation to the function that executes the logic to specify the service degradation method, 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 verify some of the basic features Hystrix brings to the table above. Let’s start all the Services involved, for example: Services: [Eureka-consumer-ribbon-hystrix, Eureka-client].
To trigger the service degradation logic, we can add some delay to the service provider Eureka-client’s logic, for example:
@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, we will get fallback. From the Eureka-Client console, we can see that the service provider outputs the result that it was intended to return, but since there was a 5 second delay before returning, and the service consumer triggered the service request timeout exception, the service consumer executed it using the degrade logic specified in the HystrixCommand annotation. The result of the request therefore returns a fallback. This mechanism provides basic protection for its own services, and also provides an automatic service degradation switchover mechanism for abnormal situations.
From now on, I will record the construction process and essence of springCloud micro-service cloud architecture recently developed, to help more friends who are interested in developing Spring Cloud framework, and I hope to help more good scholars. Discuss the process of building the Spring Cloud architecture and how it can be applied to enterprise projects. Source: source minglisoft. Cn/honghu/tech…