In the current microservice architecture, an important problem is that calls between services will generate a lot of delays and errors, which will affect the performance and reliability of the entire application. To solve this problem, Netflix developed a library called Hystrix, which provides a mechanism to achieve fault tolerance, which can help deal with inevitable delays and failures in distributed systems. Hystrix provides high-availability and high-performance solutions for distributed systems by using technologies such as isolation technology, circuit breaker mode, and resource pools.

1.2. Features and advantages of Hystrix

Hystrix is an open source fault-tolerant framework, which is mainly used in service fusing, service degradation, thread pool isolation and other aspects in distributed systems. The following are the features and advantages of Hystrix:

Service fuse: Hystrix can automatically fuse unavailable services based on the failure rate of requests and the total number of requests to prevent service avalanche.

Service degradation: Hystrix can return an alternative result through the fallback method to ensure the availability of the system when the service is unavailable.

Thread pool isolation: Hystrix uses an independent thread pool for each service to process requests, preventing the stability of the entire application from being affected by a service timeout or error.

Real-time monitoring: Hystrix provides real-time monitoring and reporting functions, which can easily monitor service calls and failures.

Adaptive control: Hystrix can adaptively control the traffic and concurrency of services to prevent the system from being overloaded.

Pluggability: Hystrix can be integrated with other open source frameworks and technologies, such as Spring Cloud, Netflix Eureka, etc., to provide richer functions and higher performance.

2. The basic concept of Hystrix

2.1, Hystrix command (HystrixCommand)

It provides a wealth of service call control and management functions, making it easier for us to achieve the reliability and stability of service calls; it is a class provided by Hystrix for encapsulating service call logic. Its main function is to wrap a service call request into a HystrixCommand object and provide the following features:

Timeout control: HystrixCommand allows setting the timeout period. When the service call time exceeds the specified time, Hystrix will interrupt the service call and return a fallback response.

Fuse control: HystrixCommand can perform fusing control on service calls. When the service call failure rate exceeds the specified threshold, Hystrix will turn on the fusing protection, forward the service call request to the fallback logic, and temporarily stop the service call request.

Degradation control: HystrixCommand provides fallback logic. When a service call fails or times out, Hystrix will automatically call the fallback logic to return a response, avoiding forwarding failed or timed-out service call requests to downstream services, causing an avalanche effect.

Statistics: HystrixCommand can count the success rate, response time, error rate and other information of service call requests, which is convenient for developers to analyze the performance and stability of service call requests.

Request caching: HystrixCommand can cache service call requests to avoid repeated service call requests and improve system performance and response speed.

2.2, Hystrix thread pool (HystrixThreadPool)

It provides an independent thread pool for each Hystrix command instance to execute commands. In Hystrix, the thread of command execution and the thread of command call are separated, so the function of Hystrix thread pool is to provide an isolated thread pool for command execution.

The configuration of the Hystrix thread pool can be configured through HystrixThreadPoolProperties, including parameters such as thread pool size, queue size, and thread survival time. The thread pool size determines the maximum number of commands that can be executed at the same time. If the maximum number is reached, subsequent commands will be rejected. The queue size means that when all threads in the thread pool are executing commands, new commands will be put into a queue for execution. If the queue is full, subsequent commands will be rejected. The thread survival time determines the longest survival time of an idle thread.

The advantage of using the Hystrix thread pool is that commands can be isolated and controlled at a finer granularity, avoiding the problems of thread pool exhaustion and resource contention. At the same time, by adjusting the thread pool size and queue size, the throughput and performance of the system can be improved while ensuring the quality of service.

2.3, Hystrix fuse (Hystrix Circuit Breaker)

Used to implement the circuit breaker pattern to protect communication between a service caller and callee. The fuse is a mechanism to prevent cascading failures of applications. When an error or anomaly reaches a certain threshold within a certain period of time, the fuse will automatically trip, directly reject subsequent requests, and return directly to a preset within a period of time Error response to avoid the impact of a large number of invalid requests on the service.

HystrixCircuitBreaker can monitor the execution of Hystrix commands, and judge whether to open the fuse according to a certain strategy. When the fuse is opened, Hystrix will short-circuit the request, no longer make calls, and directly return the preset error response. When the fuse is closed, Hystrix will resume the normal call flow.

The implementation of HystrixCircuitBreaker depends on HystrixCommand and HystrixThreadPool, which dynamically adjusts the state of the fuse according to the execution of these two components. When the number of HystrixCommand execution failures exceeds the threshold, the fuse will be opened; when the number of HystrixCommand execution successes exceeds the threshold, the fuse will be closed.

HystrixCircuitBreaker provides a variety of configuration parameters that can be used to customize the behavior of the circuit breaker. For example, we can set the sleep time when the fuse is opened, the error rate threshold, the window period, and so on. These parameters can be configured through annotations of HystrixCommand and HystrixThreadPool, or through configuration files.

3. Use of Hystrix

3.1, Hystrix configuration

3.1.1, code configuration

The configuration of Hystrix is very flexible and can be adjusted and optimized according to specific business scenarios. Here are some configurations:

Configure in the code through classes such as HystrixCommandProperties or HystrixThreadPoolProperties.
Configure through annotations, such as using @HystrixCommand annotations on the methods that need to be executed, and setting attributes such as fallbackMethod and commandProperties in the annotations.
By configuring in the configuration file, such as setting related properties in application.properties or application.yml.

3.1.2 Introduction to Hystrix configuration properties

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: command execution timeout, the default is 1000 milliseconds.

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: command execution timeout, the default is 1000 milliseconds.

hystrix.command.default.execution.timeout.enabled: Whether to enable command execution timeout, the default is true.

hystrix.command.default.execution.timeout.enabled: Whether to enable command execution timeout, the default is true.

hystrix.command.default.circuitBreaker.requestVolumeThreshold: The request volume for the circuit breaker to open, the default is 20.

hystrix.command.default.circuitBreaker.errorThresholdPercentage: Error rate threshold, the circuit breaker will open after reaching this value, the default is 50.

hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds: The time to sleep after the circuit breaker is opened, the default is 5000 milliseconds.

hystrix.command.default.metrics.rollingStats.timeInMilliseconds: The size of the statistical time window, the default is 10000 milliseconds.

hystrix.threadpool.default.coreSize: The number of core threads in the thread pool, the default is 10.

hystrix.threadpool.default.maxQueueSize: The maximum length of the thread pool queue, the default is -1, which means using SynchronousQueue.

hystrix.threadpool.default.queueSizeRejectionThreshold: queue rejection threshold, when the queue length reaches this value, new requests will be rejected, the default is 5.

3.2. How to use Hystrix commands in code

Use the HystrixCommand.Setter object to set the group name and execution timeout of the Hystrix command

3.2.1. Define Hystrix commands

Hystrix commands can be defined by inheriting the HystrixCommand class and implementing the run() and getFallback() methods. The run() method is used to execute the actual business logic, and the getFallback() method is used to define the fallback logic when the command execution fails or times out.

public class MyHystrixCommand extends HystrixCommand<String> {
    
    private final String name;

    public MyHystrixCommand(String name) {
        super(HystrixCommandGroupKey.Factory.asKey("MyHystrixCommandGroup"));
        this.name = name;
    }

    @Override
    protected String run() throws Exception {
        // 实际的业务逻辑
        return "Hello " + name + "!";
    }

    @Override
    protected String getFallback() {
        // 命令执行失败或超时时的回退逻辑
        return "Fallback for " + name;
    }
}

3.2.2. Execute Hystrix commands

Where a Hystrix command needs to be executed, create an instance of MyHystrixCommand and call the execute() method to execute the Hystrix command. For example:

String result = new MyHystrixCommand("World").execute();

3.2.3, Hystrix configuration

The behavior of Hystrix commands can be tuned through configuration. The behavior of the command can be configured by setting the HystrixCommand.Setter object in the MyHystrixCommand constructor. For example:

public MyHystrixCommand(String name) {
    super(HystrixCommand.Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("MyHystrixCommandGroup"))
            .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
                    .withExecutionTimeoutInMilliseconds(500)));
    this.name = name;
}

3.3. How to use the Hystrix monitoring panel

Create a Maven project and add the following Hystrix dependencies:

Hystrix-metrics-event-stream: Output Hystrix monitoring metrics to the browser in the form of SSE (Server-Sent Events).
Hystrix-codahale-metrics-publisher: Output Hystrix monitoring indicators in the form of Dropwizard Metrics.
Hystrix-dashboard: Hystrix's dashboard, you can easily view Hystrix's fuse, isolation, degradation and other indicators.
Hystrix-turbine: aggregate and display the data of multiple Hystrix Dashboards for centralized management.
Hystrix-examples: Hystrix sample code, including the basic usage of Hystrix, the use of Hystrix Dashboard, the use of Turbine, etc.

3.3.1. Add Hystrix Dashboard dependency package to the application

<dependency>
    <groupId>com.netflix.hystrix</groupId>
    <artifactId>hystrix-core</artifactId>
    <version>1.5.18</version>
</dependency>

3.3.2. Use in code`@HystrixCommand`

Use annotations in the code @HystrixCommandto mark methods that require fault tolerance and delay tolerance, and specify the fallback method in the annotation:

@HystrixCommand(fallbackMethod = "defaultHello")
public String hello(String name) {
    // 正常业务逻辑
    // ...
}

public String defaultHello(String name) {
    // fallback 逻辑
    // ...
}

3.3.3. Start Hystrix Dashboard in the main class:

@SpringBootApplication
@EnableHystrixDashboard
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

3.3.4. Access in the browser

Access http://localhost:port/hystrix, enter the URL address of Hystrix Stream on the interface, for example: http://localhost:port/hystrix.stream, click the Monitor Stream button, and you can see the monitoring panel. In the monitoring panel, you can view information such as the execution status of each Hystrix command, the status of the fuse, and the requested traffic.

Note: The Hystrix Dashboard monitoring panel needs to be used in conjunction with Hystrix Stream. Here is managementrelated to the Spring Boot Actuator module, which is used to start the monitoring endpoint of the application. This configuration item needs to be added in the application.propertiesor file. application.ymlHystrix Stream can be enabled by adding the following configuration items:

management.endpoints.web.exposure.include=hystrix.stream

Fourth, the working principle of Hystrix

4.1, thread pool isolation

Two resource isolation strategies are provided in Hystrix: thread pool isolation and semaphore isolation.

Thread pool isolation: Thread pool isolation will create a thread pool for each dependency to process requests from that dependency. Different dependent thread pools are isolated from each other. Even if dependency A fails and the thread pool resources are exhausted, it will not affect Other dependent thread pool resources.

isolation method	Whether to support timeout	Whether to support fusing	isolation principle	Whether to call asynchronously	LF
thread pool isolation	Support, can return directly	Support, when the thread pool reaches maxSize, the request will trigger the fallback interface to fuse	Each service uses a separate thread pool, and the request thread and forwarding processing thread are not the same	It can be asynchronous or synchronous. Look at the method of calling	Large, context switching of a large number of threads is likely to cause high machine load
Semaphore isolation	Not supported, if it is blocked, it can only be returned by calling the protocol (such as: socket timeout)	Supported, when the semaphore reaches maxConcurrentRequests. Re-request will trigger fallback	Through the counter of the semaphore, the request thread and the forwarding processing thread are the same	Synchronous call, does not support asynchronous	small, just a counter

2. Fuse mode

Hystrix is a latency and fault-tolerant library for distributed systems, which can protect services or systems from continuing to work under high load or dependent component failures. Hystrix was developed by Netflix and is now part of Spring Cloud.

The core principle of Hystrix is the Circuit Breaker Pattern. A circuit breaker is a powerful fault tolerance mechanism that protects an application from additional damage in the event of a failure. In a distributed system, if one service fails, other services may be affected, causing the entire system to fail. Hystrix's fuse mode is able to protect in this case.

Hystrix's fuse mode is implemented by means of a circuit breaker. When there is a problem with a service request, Hystrix will cache the result of the request inside the circuit breaker. If there are consecutive request failures, the circuit breaker will switch to the open state, and new requests will no longer be sent directly to the service, but will return a preset fallback result. Periodically, the circuit breaker will try to recheck the service for a certain period of time, and if the check is successful, the circuit breaker will switch to the closed state, otherwise it will remain open.

Hystrix's circuit breaker mode also includes a counter called circuit breaker, which is used to record the number of failed requests within a period of time. When a preset threshold is reached, the circuit breaker will be opened. After the circuit breaker is turned on, the request for the service will no longer be sent directly to the service, but the fallback result will be returned directly to avoid a greater burden on the service. Within a certain period of time, Hystrix will periodically try to close the circuit breaker. If it detects that the service is back to normal, the circuit breaker will be closed, otherwise it will continue to remain open.

In short, the fuse mode of Hystrix can effectively protect the services in the distributed system and prevent the failure of the entire system due to the failure of a certain service.

3. Backup mode

The fallback mode (Fallback Mode) in Hystrix refers to the execution of backup logic when the execution of the Hystrix command fails or times out. The fallback logic should be reliable and should be able to return data or information across different application states.

In Hystrix, fallback logic is provided by the Fallback method. The Fallback method is a fallback strategy that provides some backup data or logic when the main logic fails for some reason. The Fallback method should be able to return quickly, because its purpose is to handle failure and failure recovery, not to perform complex operations for a long time.

The Fallback mode in Hystrix can be implemented in the following ways:

Annotation method: The Fallback method can be specified through the fallbackMethod attribute in the @HystrixCommand annotation.

Programming method: The Fallback method can be specified through the HystrixCommand.Setter.withFallback() method.

It should be noted that when using Hystrix, a Fallback method should be specified for each HystrixCommand. If no Fallback method is specified, an exception will be thrown when the command execution fails or times out.

Overall, fallback modes can improve system reliability and stability. By using the Fallback method, backup logic can be provided when the main logic fails, so as to ensure the normal operation of the system.

4. Response caching

Hystrix provides a response cache to cache responses to the same request to reduce the number of calls to the backend system and improve performance. During the execution of the Hystrix command, when the response cache is enabled, it will first check whether there is a corresponding response in the cache, and if so, it will directly return the response in the cache without making a request to the backend system.

The use of response caching requires setting annotations in the Hystrix command @CacheResultand HystrixCommandspecifying the cached key in it. For specific implementation, please refer to the following code:

public class MyCommand extends HystrixCommand<String> {

    private final String cacheKey;

    public MyCommand(String cacheKey) {
        super(HystrixCommandGroupKey.Factory.asKey("MyCommandGroup"));
        this.cacheKey = cacheKey;
    }

    @Override
    protected String run() throws Exception {
        // 执行具体的业务逻辑
        return "Hello World";
    }

    @Override
    protected String getCacheKey() {
        return cacheKey;
    }

    @Override
    protected String getFallback() {
        return "Fallback";
    }

    @Override
    protected Setter getCommandProperties() {
        return Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("MyCommandGroup"))
                .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
                        .withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.THREAD)
                        .withCircuitBreakerEnabled(true)
                        .withRequestCacheEnabled(true)); // 开启响应缓存
    }

    @CacheResult // 设置缓存
    @Override
    public String execute() {
        return super.execute();
    }
}

In MyCommand, we use @CacheResultannotations to enable response caching, and getCacheKey()specify the cache key in the method. In getCommandProperties()the method, we enable the request cache so that when executing the Hystrix command, the response can be obtained from the cache first. When executing execute()the method, if there is a corresponding response in the cache, the result in the cache is returned directly. Otherwise, run()the business logic in the method will be executed and the result will be cached.

It should be noted that the response cache will occupy memory space, and if the amount of data stored in the cache is too large, it may cause memory overflow. Therefore, it is necessary to reasonably set the validity period of the cache and the size of the cache to avoid adverse effects on system performance.

Five, Hystrix application scenarios

Hystrix is mainly used to solve fault-tolerant problems in distributed systems, and can be used at different levels in the system, including front-end, server, and database levels. Here are some Hystrix application scenarios:

Service call: Hystrix can prevent service avalanche problems caused by relying party errors or timeouts during service calls.
Database access: Hystrix can prevent application crashes caused by too many database connections or database access errors when the application accesses the database.
Network resource access: Hystrix can prevent application crashes caused by resource unavailability or timeout when the application accesses external resources.
Microservice architecture: In the microservice architecture, the dependencies between services are intricate. Hystrix can provide a fault tolerance mechanism in this environment to ensure the stability of the entire system.
High-traffic applications: In the case of high concurrency, Hystrix can limit the amount of concurrent requests to prevent the system from being overloaded and causing the service to be unavailable.

In short, Hystrix is suitable for various fault-tolerant scenarios in distributed systems, and can provide protection mechanisms to prevent avalanche effects in applications and ensure system reliability and stability.

Hystrix-Let GPT tell you how to use it

1. What is Hystrix?

1.1 Background and purpose of Hystrix

1.2. Features and advantages of Hystrix

2. The basic concept of Hystrix

2.1, Hystrix command (HystrixCommand)

2.2, Hystrix thread pool (HystrixThreadPool)

2.3, Hystrix fuse (Hystrix Circuit Breaker)

3. Use of Hystrix

3.1, Hystrix configuration

3.1.1, code configuration

3.1.2 Introduction to Hystrix configuration properties

3.2. How to use Hystrix commands in code

3.2.1. Define Hystrix commands

3.2.2. Execute Hystrix commands

3.2.3, Hystrix configuration

3.3. How to use the Hystrix monitoring panel

3.3.1. Add Hystrix Dashboard dependency package to the application

3.3.2. Use in code`@HystrixCommand`

3.3.3. Start Hystrix Dashboard in the main class:

3.3.4. Access in the browser

Fourth, the working principle of Hystrix

4.1, thread pool isolation

2. Fuse mode

3. Backup mode

4. Response caching

Five, Hystrix application scenarios

Guess you like

Hystrix-Let GPT tell you how to use it

1. What is Hystrix?

1.1 Background and purpose of Hystrix

1.2. Features and advantages of Hystrix

2. The basic concept of Hystrix

2.1, Hystrix command (HystrixCommand)

2.2, Hystrix thread pool (HystrixThreadPool)

2.3, Hystrix fuse (Hystrix Circuit Breaker)

3. Use of Hystrix

3.1, Hystrix configuration

3.1.1, code configuration

3.1.2 Introduction to Hystrix configuration properties

3.2. How to use Hystrix commands in code

3.2.1. Define Hystrix commands

3.2.2. Execute Hystrix commands

3.2.3, Hystrix configuration

3.3. How to use the Hystrix monitoring panel

3.3.1. Add Hystrix Dashboard dependency package to the application

3.3.2. Use in code@HystrixCommand

3.3.3. Start Hystrix Dashboard in the main class:

3.3.4. Access in the browser

Fourth, the working principle of Hystrix

4.1, thread pool isolation

2. Fuse mode

3. Backup mode

4. Response caching

Five, Hystrix application scenarios

Guess you like

3.3.2. Use in code`@HystrixCommand`