Original: Taste of Little Sister (wechat official ID: XjjDog), welcome to share, please reserve the source.

I came to this post a little late because Hystrix has gone into maintenance mode. But there are already a lot of students into the pit, so this article is timely. This article will explain some of the do’s and don ‘ts of using circuit breakers, which may bore you with detail.

The first half, the theoretical part, applies to all kinds of fuses. The second half, is the parameter part, suitable for fine tuning.

So here we go.

Generally speaking, if the emperor wants to have a comfortable night life in the micro service, he or she will have to rely on the fuse to cut off the main manager.

Times have changed. When it comes to the chief fuse manager, we have to say that his three most prominent fathers-in-law: Sentinel, or Hystrix, or possibly Resilience4J.

These three solve A class of problems, such as the famous avalanche: A→B→C call each other in sequence, but the C project is likely to have problems (heavy traffic or errors, etc.), causing threads to wait for A long time, resulting in the whole link layer down, thread resources exhaustion.

The background,

If you are using the Spring family bucket family, most of the interface calls will follow this route. We’re still talking about Hystrix here, though it’s no longer in favor.

Feign —–> Hystrix —–> Ribbon —–> Http Client (Apache Http Components /Okhttp)

The details are shown in the figure below:

Second, the configuration

First, a little theoretical stuff. It’s delicious and not expensive.

ⅰ Isolation Mode

Thread isolation (default) : A thread pool is used to store the current request, the thread pool processes the request, sets the timeout for the return of the task, and the accumulated request is stacked to the thread pool queue. In this way, thread pools need to be applied for each dependent service, which has certain resource consumption. The advantage is that it can cope with sudden traffic (when the traffic peak comes, the data can be stored to the thread pool team for slow processing).

Signal isolation: an atomic counter (or semaphore) is used to record how many threads are currently running. The request is used to determine the value of the counter first. If the maximum number of threads is exceeded, new requests to change the type are discarded. This mode is a strict thread control and immediate return mode, which cannot cope with sudden traffic (when the number of threads being processed exceeds the number when the traffic peak comes, other requests will be directly returned without continuing to request dependent services).

Ⅱ fusing

If the invocation of a target service is slow or a large number of times out, the invocation of the target service is cut off. For subsequent invocation requests, the target service is returned to quickly release resources. If the target service improves, the call resumes.

This process, you can think of it as the behavior of a fuse.

Behavior is simple, but there are many parameters to adjust.

use

1. Introduce dependencies

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

2. Set parameters

Feign: hystrix: # This parameter does not take effect if it is not configured or false enabled: true hystrix: Command: default: Execution: Isolation: Thread: Timeout = (1 + MaxAutoRetries + MaxAutoRetriesNextServer) * ReadTimeout timeoutInMilliseconds: 60000 default: coreSize: 10 maxQueueSize: 50 queueSizeRejectionThreshold: 30 keepAliveTimeMinutes: 3Copy the code

3. The configuration fallback

You are advised to use different Fallbacks for each Feign client

At this point, Hystrix is ready to take the job. Whether he gets the job done is another matter.

4. Configure other postures

When Hystrix arrived, he found that some service interfaces were finished in a second, and others returned in five to ten seconds. A one-size-fits-all configuration makes it difficult to manage many services & interfaces.

Presumably, some of you have noticed that the default keyword has been mixed into the previous configuration. This is a global configuration, so there must be local configuration.

For example, to a service, to an interface…

Hystrix: command: default: execution: isolation: Thread: timeoutInMilliseconds: 60000 ThreadPool: # CoreSize: 10 maxQueueSize: 50 queueSizeRejectionThreshold: 30 keepAliveTimeMinutes: 3 # for a particular service configuration, write base - RPC service - id: coreSize: 10 maxQueueSize: 30 queueSizeRejectionThreshold: 20 keepAliveTimeMinutes: 3 # for an interface configuration BaseApiClient# searchItemSkuList (PosSkuSearch) : coreSize: 10 maxQueueSize: 40 queueSizeRejectionThreshold: 30 keepAliveTimeMinutes: 1Copy the code

Alternatively, you can configure it using the @hystrixCommand annotation.

5. Dynamically modify the configuration

In many cases, it is not possible to modify a configuration, especially if the configuration is temporarily changed to restart the service. Dynamic refresh is the best. So we looked at hystrix’s use of Archaius to manage configuration.

Archaius is one of the open source projects of Netflix. It is a Java-based configuration management library mainly used for dynamic acquisition of multi-configuration storage. The main feature is an extension to the Apache Common Configuration class library. It can be used as a distributed configuration management dependency in cloud platform development. At the same time, it has the following features: dynamic property acquisition efficient and thread-safe configuration operations provide a callback mechanism when configuration changes can be configured through JMX operations compound configuration

So how do you do that? Here’s a simple example.

/ / remove configuration AbstractConfiguration config = ConfigurationManager. GetConfigInstance (); Hystrix.threadpool Iterable<String> Iterable = () -> config.getKeys("hystrix.threadpool"); List<Property> result = StreamSupport.stream(iterable.spliterator(), false).map(t -> new Property(t, config.getString(t, ""))) .sorted(Comparator.comparing(Property::getName)).collect(Collectors.toList()); SetProperty ("hystrix.threadpool.base-rpc.coreSize", 20); // Remove config.clearProperty(hystrix.threadpool.base-rpc.coreSize");Copy the code

Other parameters

To think hystrix is so obedient is to belittle it. Don’t forget feign, the ribbon, and the HTTP Client! A bunch of timeout parameters, the contemporary eight golden lock array

1. The feign timeout

feign:
  hystrix:
    enabled: true
  client:
    config:
      default:
        connectTimeout: 5000
        readTimeout: 5000
      rpc-pos:
        connectTimeout: 5000
        readTimeout: 8000
      xx-rpc:
        connectTimeout: 5000
        readTimeout: 12000
      order-rpc:
        connectTimeout: 5000
        readTimeout: 8000
Copy the code

Feign is exposed to the user, and Spring consciously uses feign timeout to set the ribbon and HTTP Client components behind it.

2. The ribbon timeout

# Global Configuration ribbon: ReadTimeout: 60000 ConnectTimeout: 10000 #false to only allow get method to retry OkToRetryOnAllOperations: true # Max number of next servers to retry (excluding the first server) MaxAutoRetriesNextServer: 2 # Max number of retries on the same server (excluding the first try) MaxAutoRetries: 0 # Interval to refresh the server list from the source ServerListRefreshInterval: 5000 retryableStatusCodes: Base-rpc: ribbon: ReadTimeout: 60000 ConnectTimeout: 10000 #false to only allow get method to retry OkToRetryOnAllOperations: true # Max number of next servers to retry (excluding the first server) MaxAutoRetriesNextServer: 2 # Max number of retries on the same server (excluding the first try) MaxAutoRetries: 0 # Interval to refresh the server list from the source ServerListRefreshInterval: 5000 retryableStatusCodes: 404500Copy the code

When feign sets the timeout, the Ribbon synchronizes with feign’s Settings. The Ribbon uses this timeout to guide how to set the actual implementer timeout when the interface is actually called.

Httpclient timeout

Feign: hystrix: enabled: true OKhttp: enabled: true httpClient: enabled: false // Maximum number of connections in the connection pool. The default value is 200. 500 // Maximum number of connections per IP address default 50 max-connections-per-route: 50 // Default connection timeout: 2000 ms connection-timeout: 8000 // Execution frequency of the connection pool management timer: 3000 ms by default connection-timer-repeat: 6000 // Lifetime of the connection pool. The default value is 5 time-to-live: 5 time-to-live-unit: minutesCopy the code

The basic principle of timeout setting is that the dependent’s timeout configuration overwrites the dependent’s configuration, which is implemented by the AutoConfiguration mechanism of Spring Boot

Such as: if the open feign. Okhttp. Enabled = true, then okhttp timeout is feign httpclient. The value of the connectionTimeout default 2000 milliseconds

Bottom line: Overtime — Feign decides!

Four, hystrix dashboard

It is great to be able to visualize these states, requiring the introduction of a JAR package.

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

Here’s a picture of some of the explanations for background monitoring.

(Photo from Internet)

Attached: Configuration parameter description

A, the Command Properties

The following attributes control HystrixCommand with the prefix hystrix.command. Default

1, the Execution

The following properties control how hystrixcommand-run () is executed. Of the more important parameters are: execution. The isolation. The strategy execution. The isolation. Thread. TimeoutInMilliseconds

2, Fallback

The following properties control HystrixCommand. GetFallback () how to perform. These properties apply to ExecutionIsolationStrategy. THREAD and ExecutionIsolationStrategy. SEMAPHORE.

3, Circuit Breaker

Circuit breaker properties control HystrixCircuitBreaker.

4, the Metrics

The following properties relate to executing capture metrics from HystrixCommand and HystrixObservableCommand.

5, the Request Context

These properties refer to the HystrixRequestContext function used by HystrixCommand

Second, the Command Properties

The following attributes control the HystrixCollapser behavior. The prefix: hystrix. Collapser. Default

Third, ThreadPool Properties

The following properties control the behavior of the thread pool on which Hystrix commands are executed. Most of the time, the default value is 10 threads will be very good (usually can be made smaller) prefix: hystrix. Threadpool. Default

End

This guy, he says he won’t update, and he won’t update. But our legacy system, there are a lot of modules in use, so I’ve scratched out the details. This is probably out of print, because Hystrix is the best.

This article is for collecting, not sharing. Sharing it would be a loudspeaker telling people that you’re filling a hole in a legacy system.

Xjjdog is a public account that doesn’t allow programmers to get sidetracked. Focus on infrastructure and Linux. Ten years architecture, ten billion daily flow, and you discuss the world of high concurrency, give you a different taste. My personal wechat xjjdog0, welcome to add friends, further communication.