Shulou(Shulou.com)06/01 Report--

This article mainly introduces "how to understand Spring Cloud Hystrix circuit breaker". In daily operation, I believe many people have doubts about how to understand Spring Cloud Hystrix circuit breaker. The editor consulted all kinds of data and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubt of "how to understand Spring Cloud Hystrix circuit breaker"! Next, please follow the editor to study!

I. what is a fuse break?

There are all kinds of household appliances in a family. We assume that every household appliance does not have a fuse. Once a household appliance is short-circuited one day, the whole circuit will be short-circuited and then the electrical appliances and circuits of the whole family will probably be burned out. But if each appliance entrance circuit has a fuse (circuit breaker), no matter which appliance is short-circuited, the fuse of this appliance will quickly fuse (disconnect the circuit), thus protecting the normal operation of the whole circuit and other household appliances on the circuit.

The circuit breaker mechanism in the software industry is consistent with this. In the entire microservice cluster, because one or more of the microservices are malfunctioning or blocked, if there is no fast circuit breaker mechanism, it will cause congestion in the entire microservice cluster and eventually an avalanche of the entire microservice will be dragged to death. The core mechanism of the circuit breaker mechanism is to ensure that when a micro-service fails, it can achieve a fast circuit breaker (circuit breaker) or service degradation to avoid congestion. So as to ensure the normal operation of other services in other business.

II. Design principles of Hystrix

Prevent the failure of a single service, deplete the thread resources of the entire system service container (such as tomcat), and avoid large-scale federation failure in the distributed environment. Access through a third-party client (usually over the network) relies on the service to perform fallback logic in the event of a failure, rejection, timeout, or short circuit.

Replace queuing with quick failure (each dependent service maintains a small thread pool or semaphore, which immediately denies service instead of waiting in queue when the thread pool or semaphore is full) and elegant service degradation; when the dependent service fails, it returns to normal and recovers quickly.

Provides near-real-time monitoring and alerts so that faults can be quickly detected and repaired. Monitoring information includes successful requests, failures (exceptions thrown by the client), timeouts, and thread rejections. If the percentage of errors accessing the dependent service exceeds the threshold, the circuit breaker will trip and the service will stop all requests for a particular service for a period of time.

Encapsulate all requests external systems (or requests dependent on services) into HystrixCommand or HystrixObservableCommand objects, and then these requests are executed in a separate thread. Use isolation techniques to limit the impact of the failure of any dependency on the system. Each dependent service maintains a small thread pool (or semaphore). When the thread pool is full or the semaphore is full, the service is immediately denied without waiting in line.

III. Hystrix characteristics

Request circuit breaker: when the number of Hystrix Command requests for backend service failures exceeds a certain percentage (default 50%), the circuit breaker will switch to the open state (Open). At this point, all requests will fail directly and will not be sent to the back-end service. After keeping the circuit breaker in the open state for a period of time (default 5 seconds), the circuit breaker automatically switches to the semi-open state (HALF-OPEN). At this time, the return of the next request will be judged, and if the request is successful, the circuit breaker will switch back to the closed-circuit state (CLOSED), otherwise it will switch back to the open-circuit state (OPEN). Hystrix's circuit breaker is like a fuse in our home circuit. Once the back-end service is not available, the circuit breaker will directly cut off the request chain to avoid sending a large number of invalid requests affecting the system throughput, and the circuit breaker has the ability to self-detect and recover.

Service degradation: Fallback is equivalent to a downgrade operation. For query operations, we can implement a fallback method. When an exception occurs in the request back-end service, we can use the value returned by the fallback method. The return value of the fallback method is usually the default value set or from the cache.

Dependency isolation (using bulkhead mode, Docker is a kind of bulkhead mode): in Hystrix, resource isolation is mainly achieved through thread pool. Usually when we use it, we divide multiple thread pools according to the remote service invoked. For example, if a service invokes two other services, and you use a thread pool to invoke both services, then if one service card is located and the resources are not released, the subsequent requests come again, resulting in where the subsequent requests are stuck and waiting. as a result, the A service you rely on stuck you there, exhausted resources, and caused your other B service to be unavailable. At this time, if you rely on isolation, a service invokes An and B two services, and if I have 100 threads available, I assign 50 to A service and 50 to B service, so that even if A service dies, my B service can still be used.

Request cache: for example, if a request comes to request my userId=1 data, and your later request also comes to request the same data, I will not continue to follow the original request link, but will cache the first request and return the result of the first request to the following request (see @ CacheResult, @ CacheKey, @ CacheRemove notes).

Request merge: I rely on a certain service, and I need to call N times. For example, when I check the database, I send N requests, send N SQL and get a bunch of results. At this time, we can combine multiple requests into one request and send a SQL request for querying multiple data, so we only need to query the database once, which improves the efficiency.

In Hystrix, we often use the first three points, and the latter two points are not applicable to all businesses.

Fourth, actual combat 1, add dependence

Add the `spring-cloud-starter- hystrix` module. After using Feign, we have already included the Hystrix module and the Ribbon module, which do not need to be introduced separately.

Org.springframework.cloud spring-cloud-starter-hystrix2, enable Hystrix

Add the @ EnableCircuitBreaker annotation to the startup class to indicate that circuit breakers are allowed. The following code is shown:

/ / allow circuit breaker @ EnableCircuitBreakerpublic class Application {...}

The annotations of `@ SpringCloudApplication` in the spring cloud project have already included the annotations of` @ EnableSecretitBreaker` and other micro-services. See the source code:

@ Target ({ElementType.TYPE}) @ Retention (RetentionPolicy.RUNTIME) @ Documented@Inherited@SpringBootApplication@EnableDiscoveryClient@EnableCircuitBreakerpublic @ interface SpringCloudApplication {} 3, method level fuse

Spring cloud uses http for communication, spring cloud and Eureka encapsulate the http request response operation, supporting two modes, RestTemplate and Feign mode, and Feign mode refer to other chapters. Here is a brief introduction to RestTemplate mode.

@ Servicepublic class HelloService {@ Autowired private RestTemplate restTemplate; / / request fuse comments. When there is a problem with the service, the method named helloFallBack of the fallbackMetho attribute @ HystrixCommand (fallbackMethod = "helloFallBack") public String helloService () throws ExecutionException, InterruptedException {return restTemplate.getForEntity ("http://HELLO-SERVICE/hello",String.class).getBody();} public String helloFallBack () {return" error ";}})

This is a restTemplate implementation of external service invocation, which turns on the circuit breaker mechanism with the @ HystrixCommand (fallbackMethod = "helloFallBack") flag, specifying that the service degradation method after the circuit breaker is: helloFallBack (). If the callee is abnormal at this time, the next request will enter the service degradation implementation (callback method) and fail quickly. @ HystrixCommand can also specify other configurations:

Public @ interface HystrixCommand {String groupKey () default ""; String commandKey () default ""; String threadPoolKey () default ""; String fallbackMethod () default ""; HystrixProperty [] commandProperties () default {}; HystrixProperty [] threadPoolProperties () default {}; Class

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.