instructions

Previously, we have used the ribbon to realize inter-service communication and load balancing for multiple instances of a service

Questions we may encounter:

1. Ripple effect of a service failure 2. In the case of high availability, we need features that fail quickly 3Copy the code

Hence the introduction of the Hystrix component

Hystrix is a framework with circuit breaker mechanism provided by Spring Cloud. In the microservice system, the same operation will be jointly completed by multiple different microservices, so there will be many mutual calls between microservices and microservices. As the failure of a microservice node often occurs in the distributed environment, So call failures happen, and the purpose of a fuse is to provide a mechanism to keep the program running when a remote call fails and not get stuck on a call, similar to the try-catch structure in Java, where you only go into a block of code called catch when an exception occurs.

Hystrix follows the following design principles:

1, to prevent any single rely on running out of resources (thread) 2, overload cut off immediately and quickly failure, prevent line 3, as far as possible back to protect the user from fault 4, use isolation technology (such as partition, lane and circuit breaker model) to limit the impact of any dependence on 5, through nearly real-time indicators, monitoring and warning, Ensure that faults are discovered in a timely manner. 6. Dynamically modify configuration properties to ensure that faults are recovered in a timely mannerCopy the code

Start building (see Hystrix for details)

1. Introduce dependencies

<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency> 
Copy the code

Add a dependency to client1, client2, and client3 and add @enablehystrix annotation to the main function. The other two are used directly on the Controller without introducing scenario 1

Call the getOther method

More toThen the call succeeds and we shut down client2 and Client3 instances

test

Consider: If we deactivate only one instance of the Client2 service

The test found that the first call to fallback was successful the second timeCopy the code

Our fusing mechanism has been implemented, but the SERVICE will be fusing and then normal (client1 uses the ribbon default polling load balancing mode). We check the registry and find that a container in Client2-Service is disabled. – Disabled containers are not immediately removed from the registry list.

Hystrix workflow

Construct a HystrixCommand or HystrixObservableCommand object to encapsulate the request and configure the parameters needed to execute the request in the constructor. 2. Execute commands. Hystrix provides four ways to execute commands, which are described in detail below. 3. Determine whether to use caching to respond to a request. If caching is enabled and available, directly use caching to respond to a request. Hystrix supports request caching, but requires custom startup; 4. Judge whether the fuse is open. If so, skip to step 8. Check whether the thread pool/queue/semaphore is full, if so, skip to step 8. 6, execute HystrixObservableCommand. The construct () or HystrixCommand. The run (), failure or timeout, jump to step 8; Otherwise, skip to step 9; 7. Make statistics of fuse monitoring indicators; 9. Return the request responseCopy the code

Hystrix fault tolerance mechanism

Hystrix provides fault tolerance in the following three ways: (1) Resource isolation (2) Fusing (3) Degraded Resource isolation (2) Thread pool isolation (3) SemaphoreCopy the code

Advantages and disadvantages of thread pool isolation:

1. Protect the application from dependency failures by specifying that dependency thread pool saturation does not affect the rest of the application. 2. When a new client lib is introduced, if there is a problem, it is in the lib and does not affect other content. 3. When a dependency recovers from failure, the application immediately returns to normal performance. 4. When some of the application's configuration parameters are wrong, the thread pool health will quickly detect this (by adding errors, delays, timeouts, rejections, etc.), and the parameter configuration can be corrected in real time through dynamic properties. 5. If the performance of the service changes and needs to be adjusted in real time, such as increasing or decreasing the timeout time and changing the retry times, it can be modified dynamically through the thread pool indicator without affecting other call requests. 6. In addition to the isolation benefits, Hystrix has dedicated thread pools that provide built-in concurrency capabilities that allow asynchronous facades (facade patterns) to be built on top of synchronous calls, providing support for asynchronous programming (Hystrix introduced the Rxjava asynchronous framework).Copy the code

Disadvantages:

The main disadvantage of thread pools is the increased computational overhead. Execution of each command is done in a separate thread, adding to the overhead of queuing, scheduling, and context switching. So to use Hystrix, you have to accept the overhead in exchange for the benefits it provides. Typically, the overhead introduced by thread pools is small enough that there is no significant cost or performance impact. However, for some services with very low access latency, such as relying only on memory caching, the overhead introduced by thread pools is obvious, and thread pool isolation is not suitable. We need to consider more lightweight methods such as semaphore isolation. If you don't want this overhead, you can use semaphore isolation because Hystrix uses thread pools by default for thread isolation, Using the signal isolation need to display to the property execution. The isolation. The strategy set to ExecutionIsolationStrategy. SEMAPHORE, configuration SEMAPHORE number at the same time, the default is 10. When the client needs to make a request to the dependent service, it must obtain a semaphore first to initiate the call. Because the number of semaphore is limited, when the number of concurrent requests exceeds the number of semaphore, the subsequent requests will be directly rejected and enter the fallback process.Copy the code

fusing

Hystrix reports the status of success, failure, timeout, and rejection to the fuse corresponding to each commandKey during the operation. The fuse maintains and collects statistics on these data, and determines whether to turn on the fuse switch based on the statistics. If opened, fuses subsequent requests and returns quickly. After a certain period of time (5 seconds by default), the fuse will try to open half and put in some traffic requests, which is equivalent to a health check for the dependent services. If the request is successful, the fuse will close.

demotion

When a service is down, the server will no longer be called. The client can prepare a local fallback callback to return a default value. Although the service level is down, it is better to use it than to hang up